signals handlers and threads

[Ara.T.Howard]

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
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[Rick Nooner]

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?

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

 

[Ara.T.Howard]

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
--
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze. --Nagarjuna
===============================================================================

 

[Rick Nooner]

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