Re: Thread support plan with initial patch

[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.

Good point.  My idea is it's for all thread implementations.

This design issue is that:
        What model we provide to low-level Guile programmers?

Here, "low-level" means C implementation.

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

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

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

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

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

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

Besides, whichever low-level implementation we adopts, we could
provide good behavior in high level.
--