From: Brian Candler <B.Candler@...>
Date: 2003-04-25T19:46:56+09:00
Subject: Re: asynchronous ruby

On Fri, Apr 25, 2003 at 06:37:45PM +0900, daniel wrote:
> --
> These procedures provide a safe mechanism for dealing 
> with asynchronous events such as signals. If an event 
> such as a signal occurs while a Tcl script is being 
> evaluated then it isn't safe to take any substantive 
> action to process the event. For example, it isn't 
> safe to evaluate a Tcl script since the interpreter 
> may already be in the middle of evaluating a script; 
> it may not even be safe to allocate memory, since a 
> memory allocation could have been in progress when the 
> event occurred. The only safe approach is to set a flag 
> indicating that the event occurred, then handle the event 
> later when the world has returned to a clean state, such as 
> after the current Tcl command completes.
> --

Ruby handles signals in the same way. If it's in the middle of doing
something then all the signal handler does is sets a flag, which gets
processed at the next sensible opportunity.

But I don't think you can use signals as a way of communicating between
threads. You'd need a separate mechanism whereby Ruby blocks on some other
thread-safe entity (a semaphore perhaps) and takes an action.

Perhaps you could just set up a pipe between your threads. Ruby can select()
on one end the pipe, waiting for you to send a message down it.

Regards,

Brian.