Re: srfi-18 requirements

[Julian Graham]

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