Re: Does Guile have a thread limit?

[Mark H Weaver]

Hi,

Taylan Ulrich Bayirli/Kammer <address@hidden> writes:

> address@hidden (Taylan Ulrich "Bayırlı/Kammer") writes:
>
>> While C code using up many FDs and then calling scm_with_guile() might
>> abort --which should be a rare case--, `call-with-new-thread' neatly
>> raises an exception ... almost.  In the REPL, when I repeatedly enter
>> our test-case snippet of launching 1k sleeping threads, I manage to
>> make Guile hang.  In case anyone's interested, here's the backtraces
>> of all threads when I attach with GDB: http://sprunge.us/VZMY
>
> I solved this now, the problem was that I didn't think about cleanup at
> all after a failed thread initialization; though in this case the only
> thing that needed to be done was to call GC_unregister_my_thread.
>
> Does anyone have time to review this patch?  It passes `make check' and
> neatly throws an exception when a thread fails to initialize due to
> running out of FDs.

One serious problem with this patch is that it changes the API (and ABI)
of 'scm_init_guile'.  This function has never returned an error code and
thus has always been assumed to succeed.  This patch would allow it to
fail and return an error code that no one ever checks.  There are other
problems with the patch, but I'm not sure it's worth enumerating them
because I think this is the wrong approach.

The fundamental problem here is that currently, programs must be careful
to limit the number of threads that have ever been put into Guile mode,
just as they must limit the number of open files.  If they do that, then
they won't ever encounter this error.  If they run out of FDs then they
are screwed, and this patch doesn't change that fact, it merely trades
one kind of ungraceful exit for another.

A proper solution would eliminate that limitation.  Once we've done
that, then there will no longer be a need for these new APIs that you
would introduce, nor for the error-prone code paths that they would
entail.

> (Well, in the REPL, one gets flooded with readline errors when that
> fails to acquire an FD because the succeeding threads ate up all the
> available ones, but that's a different issue.)

I don't think it's a different issue.  Rather, I think it demonstrates
that this patch doesn't really solve the problem in practice.

      Mark