[email protected] (Taylan Ulrich "Bayırlı/Kammer") skribis:
> [email protected] (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’.
