Hi Neil,
> Would that also mean that you could revert the change to the spawning > of signal_delivery_thread()? Of course. > As this stands, I'm concerned that > you're introducing an observable difference. For example: program > calls sigaction specifying a signal handler and a specific thread; > later that thread exits, then the signal is raised. I believe this > will cause signal_delivery_thread/scm_system_async_mark_for_thread to > raise a "thread has already exited" exception, which is currently > reported. Yeah, it's "reported," but you can't do anything about it programmatically, so all you can really do is observe it. But, yes, point taken. > No, I meant how the srfi-1 map (defined by module (srfi srfi-1)) is > distinct from the core Guile map (defined by (guile)). > > In other words, the suggestion is that the SRFI-18 implementation of > join-thread would not be a core binding, but would come from (srfi > srfi-18). Well, maybe. Except that I don't really see the benefit to thread API users who weren't depending on idiosyncratic threading behavior. And it seems to me that SRFI-1 had more behavioral conflict with Guile primitives than does SRFI-18, so if SRFI-18 functionality can be introduced by extending the core rather than providing a parallel implementation, then there'll be fewer tears for everyone. But I'm arguing this as the guy who already wrote it like that, so a grain of salt is probably in order. > Yes, please. Can you include the make_jmpbuf fix discussed above, > assuming that it passes all your tests? Will do, unless somebody has a sudden twinge regarding the utility of CRITICAL_SECTION_START in that function. I'll try to get that done this weekend. Regards, Julian
