Re: Thread support plan with initial patch

[Neil Jerram]

>>>>> "NIIBE Yutaka" == NIIBE Yutaka <address@hidden> writes:

    NIIBE Yutaka> Neil Jerram wrote:
    >> Why is this, and will this be the case for all thread
    >> implementations, or only POSIX?  Only a few days ago there was
    >> a discussion here (or perhaps guile-user) in broad support for
    >> the asynchronous approach.

    NIIBE Yutaka> We could take two different approaches in low-level
    NIIBE Yutaka> implementation.

    NIIBE Yutaka>   (1) Fully asynchronous implementation Any potions
    NIIBE Yutaka> of the code may be interrupted.

This is what I would call "synchronous" ...

    NIIBE Yutaka>   (2) Synchronous implementation Basically, the code
    NIIBE Yutaka> is not interrupted.  Only when programmers
    NIIBE Yutaka> explicitly call the signal cacthing routine, the
    NIIBE Yutaka> execution will be interrupted.

... and this "asynchronous"!  So in fact there is no issue except one
of terminology.  Note that Guile itself implicitly refers to (2) as
"asynchronous", since the implementation is in terms of "system
asyncs".

    NIIBE Yutaka> The implementation of Guile till 1.3.4 is (1), and
    NIIBE Yutaka> now is (2), I believe.

Exactly - that's what the thread that I referred to was talking about.

    NIIBE Yutaka> With threads support, signal handling of the model
    NIIBE Yutaka> (1) is very difficult to implement.  If signal
    NIIBE Yutaka> handler is invoked with holding some locks, it
    NIIBE Yutaka> results dead-lock.  Practically, there's no way use
    NIIBE Yutaka> of signal in threaded program.

Quite.

    NIIBE Yutaka> For model (2), because the points where signal
    NIIBE Yutaka> handlers are invoked are defined, the semantics of
    NIIBE Yutaka> signal handling is much cleaner.

I agree.  I seem to remember, though, that with pthreads there are two
kinds of signal: those that are delivered synchronously to the thread
that caused them - SEGV, FPE etc. - and those that are not associated
with a particular thread and so require an application-designated
thread to receive them - ALRM, CHLD, TERM etc.  How would Guile decide
how to dispatch the second kind of signal?

Best regards,
        Neil