From: daniel <offstuff@...>
Date: 2003-04-25T21:40:08+09:00
Subject: Re: asynchronous ruby

Brian Candler wrote:
> 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.

afaik, ruby is not thread-safe.
tcl is (since version 8 or so).

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


I'll try this, thx.


daniel