Re: Does Guile have a thread limit?

[Ludovic Courtès]

address@hidden (Taylan Ulrich "Bayırlı/Kammer") skribis:

> address@hidden (Ludovic Courtès) writes:
>
>> Hi,
>>
>> Thanks for looking into it!
>>
>> However, I see two issues:
>>
>>   1. We can’t really change ‘scm_with_guile’, because it’s a public
>>      function, and it’s been there “forever”.
>
> OK, I expected this.  We could just make that one abort then, and keep
> the exception in `call-with-new-thread' and similar.  (Or are there
> other plausible ways to signal an error in C, other than return value
> and error-pointer argument?)

No, that’s a problem.

>>   2. Fundamentally, there should be no limit other than that imposed by
>>      the OS (or hardware resources) on the number of threads.
>>
>> Doug Evans (hi! :-)) was looking at signal-handling code, suggesting he
>> may come up with another implementation of signal-handling that does not
>> involve the current signal delivery machinery.
>>
>> That machinery happens to also be the root of the problem at hand,
>> because it mandates this pipe between newly-created threads and the
>> signal-delivery thread.
>>
>> So I think this is really the way to go.
>
> After that change is done, will we be able to guarantee that thread
> initialization is *always* successful?

No, we can never guarantee that.

We could introduce a variant of scm_with_guile2, but I’m not sure
there’s anything sensible that can be done anyway.

What matters, though, is for Scheme-level procedures that create threads
to not abort.

Ludo’.