Re: a thread question

[Mikael Djurfeldt <mdj@nada.kth.se>]

Aleksandar Bakic <bakicale@cps.msu.edu> writes:

> 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