[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?) > 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? I see that the return value of pthread_create() is already handled, so if we can guarantee that everything happening after it will always succeed in initializing the created thread, then this propagation of errors is indeed redundant. Taylan
