Re: Race condition on loading packages from 2 maxima processes in parallel?

I just pushed the commit that includes the "recompile and load" logic.

Getting back to the original topic: the race conditions when multiple
processes try to load/compile the same package in parallel ...
I'd like to introduce a new construct called with_lock to Maxima. It would
work like this:

with_lock([lockfile = "/path/to/lockfile", timeout = 60, on_timeout =
abort],
    /* Code to execute while holding the lock ... */
);

timeout and on_timeout are optional, defaulting to infinite timeout.
This tries to acquire the lock using the given lockfile path for timeout
seconds (or infinitely long) before either ...

   - aborting (on_timeout = abort, the default), then with_lock will raise
   an error.
   - trying to forcefully acquire the lock (on_timeout = force), raising an
   error if that didn't work. This is useful for cases where the process that
   had acquired the lock has apparently died and was unable to clean up the
   lockfile.

If the lock was successfully acquired, then the inner code is executed, and
with_lock returns whatever the code evaluates to. The lock is released
afterwards, using unwind-protect.

We can use the ANSI-compliant locking mechanism I described earlier in this
discussion as the default implementation.
For certain Lisps, we may be able to use implementation-specific functions
like sb-posix:flock on SBCL, which would be more robust in cases of a
process dying while holding a lock.

Building on top of this mechanism, we can then extend $load to accept
a keyword argument named lock, which can have the following formats:

   - false (default): Disable locking mechanism.
   - true: Enable locking mechanism with infinite timeout.
   - [timeout, action]: Enable locking mechanism. After waiting for timeout
   seconds without being able to obtain the lock, either abort (action =
   abort) or force acquiring the lock (action = force).

To prevent permission errors, the lockfile is created in *maxima-tempdir*,
and its name will be made up of "maxima-", the name of the file being
loaded, and a hash of its "real path" and the extension ".lock", e.g.
/tmp/maxima-lapack-47182512.lock when doing load(lapack). Doing it this way
ensures that two files with the same name that sit in different directories
don't collide, and users can quickly find the lockfile in case it ever
needs to be deleted manually.

I'd appreciate feedback on this proposal, and I'd be willing to implement
it.

Best regards
David Scherfgen

Am Do., 18. Juni 2026 um 00:14 Uhr schrieb Raymond Toy <
[email protected]>:

> On 6/17/26 2:33 PM, David Scherfgen wrote:
>
> Raymond Toy <[email protected]>:
>
>> On 6/17/26 1:29 PM, David Scherfgen wrote:
>>
>> I think the objection was "Why risk changing something that works?". And
>> actually, that's true. Is there something broken with the old
>>
>> Yeah, but then, for many people, they’d still be using Maxima 5.9 because
>> it still works.
>>
>
> But we've fixed countless bugs since then (and probably added a few more,
> but I bet the overall number has gone down).
>
> It was meant as a (bad) joke.
>
>
> Are there bugs in our old mk-defsystem that affect us?
>
> Don’t know. I don’t think we really exercise it’s capabilities much. I
> don’t know how much the current 3.9.x differs from the version we’re using.
> Probably not a lot of changes, but getting the warnings cleaned up is
> certainly nice.
>
> It’s not much different from the fact that we still support texinfo 5.x
> even though there have been huge changes since then with texinfo 7.3. 6.8
> is the oldest version that actually generates half-decent HTML. 7.3 let’s
> me do syntax highlighting for HTML, which I do use locally.
> &#8203;
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss