[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Thread support plan with initial patch
From: |
Neil Jerram |
Subject: |
Re: Thread support plan with initial patch |
Date: |
02 Apr 2001 21:42:05 +0100 |
User-agent: |
Gnus/5.0808 (Gnus v5.8.8) Emacs/20.5 |
>>>>> "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
Re: Thread support plan with initial patch, Neil Jerram, 2001/04/02
Thread support plan with initial patch, NIIBE Yutaka, 2001/04/02
- Re: Thread support plan with initial patch, Keisuke Nishida, 2001/04/03
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/03
- Re: Thread support plan with initial patch, Mikael Djurfeldt, 2001/04/05
- Re: Thread support plan with initial patch, NIIBE Yutaka, 2001/04/06
- Re: Thread support plan with initial patch, Dirk Herrmann, 2001/04/06