From: Rick Nooner <rick@...>
Date: 2005-09-21T12:45:04+09:00
Subject: Re: signals handlers and threads

On Wed, Sep 21, 2005 at 10:18:37AM +0900, Ara.T.Howard wrote:
> 
> great - this is actually what i am doing:
> 
>   trap 'INT' { handle_requests }
> 
>   ...
> 
>   loop{ sleep }
> 
>   ...
> 
>   def handle_requests
>     Thread::new{ ... }
>   end
> 
> so perhaps i'm o.k.  the code is running on linux and cygwin now - but i'm
> having issues with Process::kill returning EINVAL on windows...  googling...

That's certainly a good Unix solution.

> in my case the handler scan a directory for new requests - so it's not even
> important if any signals are missed while handling another.  so long as the
> scanning takes place.

Just for completeness sake, Unix (BSD 4.3 and up, Sys V, and I think Linux)
provide reliable signals so the handler should be invoked once per signal sent.
Handlers don't have to be reentrant.

> basically i'm working on a new model for acgi whereby
> 
>   - c program intercepts request, marshals env and stdin to file
>   - signals ruby server, which basically loops handling requests
>   - c program waits for signal from ruby server
>   - c program relays stdout and stderr written from ruby server
> 
> sounds like too much work - but if you consider it for while it provides the
> highests throughput for the server since a separate thread can be spawned 
> for
> each request - something you can't do when you need to write to STDOUT, etc.
> i haven't gotten it work yet

Sounds like a good approach.

> but i'm worried the signal handling won't map
> well to windows...

Can't help you there ;-)

Rick

-- 
Rick Nooner
rick@nooner.net
http://www.nooner.net