Re: Maxima and thread safety (was: A fix for SBCL error "thread local storage exhausted" when creating too many rules)

Thanks for doing the experiment. It's what I would have expected, but it's
good to see concrete evidence.

With AI coding assistants, it's not unthinkable that core Maxima code could
be made thread-safe without an enormous effort, but I'd be concerned that
this would cause new bugs and complicate the code base, with no advantage
for the vast majority of our users. There are simpler and more pervasive
problems I'd attack first.

       -s




On Sun, Jun 7, 2026, 10:56 David Scherfgen via Maxima-discuss <
[email protected]> wrote:

> Following up on the discussion about Maxima's thread safety ...
>
> I've been playing around a bit with Michel's
> distribute_over_tranches_thread.lisp
> <https://github.com/maxima-project-on-github/maxima-packages/blob/master/mtalon/maxima-parallel/distribute_over_tranches_thread.lisp>.
> It works nicely when the evaluated expressions are free of side effects
> ("pure functions").
>
> Unfortunately, Maxima has many hidden side effects that are surprising to
> the average user. The following innocent looking example simply creates
> Maxima variables v1, v2, v3, ..., v10000 in 16 parallel threads:
>
> distribute_over_tranches('(concat('v, i) :: i), i, 10000, 16)$
>
> Note: The double-colon operator :: is like :, but it evaluates its
> left-hand side.
>
> Now that looks completely safe, right? After all, each parallel evaluation
> creates a different variable. But under the hood, new variables are added
> to $values, and being a true global variable, this is not thread-safe.
> Different threads manipulate the $values list in parallel, getting in
> each other's way. After executing the above line, let's see how many
> variables Maxima thinks exist:
>
> length($values);
> 9544 /* oops, not 10000! (non-deterministic) */
>
> If we start evaluating limits in parallel, it breaks Maxima completely:
>
> distribute_over_tranches('(limit(abs(x-i)/(x-i), x, i)), i, 100, 100);
>
> This prints lots of low-level errors, and afterwards, Maxima is in a
> corrupted state where even regular, non-parallelized limits don't work any
> more. This is probably caused by database facts being added by limit,
> which is also not thread-safe, but I'm not sure. Integrals are equally
> problematic.
>
> These experiments confirm that while parallel evaluation of pure functions
> is achievable, parallel mutation of the Maxima environment is currently
> impossible without deep architectural changes, which, given the complexity
> and age of the codebase, are highly challenging.
>
> Best regards
> David Scherfgen
>
>> _______________________________________________
> Maxima-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/maxima-discuss
>

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