> Since GUILE threads are not OS threads, they cannot block on an OS
> call.
Since Guile threads only make context switches at certain "safe
points" during evaluation, you can be sure that no context switches
occur during a call to any non-Guile function.
(Also, you can be completely sure that if the OS thread running Guile
goes to sleep, so will all Guile threads.)
> However, I encounter very often a need to have a thread that will
> not busy-wait but block on an OS call. If I use an OS thread, then I
> cannot invoke GUILE if GUILE was initialized in an other OS
> thread. The question is: Could I have an OS thread to be a peer with
> a GUILE thread, so that the OS thread can signal the condition
> variable that the GUILE peer-thread is blocked on (upon a blocking
> OS call in the OS peer-thread has completed)? I mean, to signal the
> condition variable using mostly C/C++ code that calls COOP C
> routines in a way that will not cause GUILE to crash.
I don't know if this is possible in some way. I have to think about
this one. But I can say that it would be possible to let the Guile
thread block on an OS condition variable, and let the non-Guile thread
signal this variable.
> Is it possible to provide such a functionality (just signaling
> condition variables, nothing more)?
I'll check and return to you.
Best regards,
/mdj