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

On 6/17/26 10:48 PM, David Scherfgen wrote:

> 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.
>
The timeout mechanism seems dependent on the support from lisp. Is it 
reasonably portable?
>
>
> 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.
So basically, this is for locking operations when loading a file causes 
other files to be compiled? So a user in general won’t know what keyword 
to use unless they’ve already determined that it compiles other files? 
IIRC sometimes such things are silently compiled so there’s no 
indication that lots of things are being compiled.

Perhaps such information could be passed to the file being loaded (via a 
defvar or something?) to acquire the lock when mk:oos (or asdf:oos) is 
used or if files are manually compiled? This is really the issue being 
solved here, right?

>
> 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;
>
&#8203;

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