how do signal handlers affect threads? specifically, if a resource must be
accessed by only one thread at a time and also is accessed from a handler,
what protection should be used?
cheers.
-a
I smell deadlock issues. I have always delegated any shared resource action
required by a signal handler to another thread.
The problem is that a signal is an async event that can interrupt your process
in an indeterminate state. You should do as little as possible in the signal
handler and delegate any real work to something in the main flow of the program,
say another thread.
One way is to set up a queue where the reader is the other thread that
actually does whatever is required by the signal handler with the shared resource.
Rick
···
On Wed, Sep 21, 2005 at 09:04:05AM +0900, Ara.T.Howard wrote:
how do signal handlers affect threads? specifically, if a resource must be
accessed by only one thread at a time and also is accessed from a handler,
what protection should be used?
--
Rick Nooner
rick@nooner.net
I smell deadlock issues. I have always delegated any shared resource action
required by a signal handler to another thread.
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...
The problem is that a signal is an async event that can interrupt your
process in an indeterminate state. You should do as little as possible in
the signal handler and delegate any real work to something in the main flow
of the program, say another thread.
right-o. that's the approach i'm taking alright.
One way is to set up a queue where the reader is the other thread that
actually does whatever is required by the signal handler with the shared
resource.
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.
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 - but i'm worried the signal handling won't map
well to windows...
thanks for the reply.
cheers.
-a
great - this is actually what i am doing:
trap 'INT' { handle_requests }
...
loop{ sleep }
...
def handle_requests
Thread::new{ ... }
endso 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 serversounds 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
···
On Wed, Sep 21, 2005 at 10:18:37AM +0900, Ara.T.Howard wrote:
--
Rick Nooner
rick@nooner.net