On Wed, 19 Mar 2008 03:16:05 +0900, Roger Pack <rogerpack2005 / gmail.com> wrote:
> In response to Mental's questions of concurrency problems for raises
> injected whilst you are in the middle of handling raises, some options
> that might help:
> 
> 1) protect the queue with mutexes--add them to the end of the queue
> atomically.

This would deadlock if the handler happened to fire while the queue's
lock was held.  Generally, locking doesn't mix with anything that can
interrupt or suspend the execution of a thread at an arbitrary time.

> 2) dare I say it, require the exception handling to be either within or
> without of an "uninterruptible block" --that is, allow the exception
> handling to be interrupted (itself), or prevent it from being
> interrupted, always, to provide for sanity.

That's a good point -- besides conflicts between the handler and whatever
the recipient thread is running at the time, you do also need to be
concerned with conflicts between multiple handler instances (if that
is allowed).

> So I guess the best way to deal with it would be to surround queue
> addition with mutexes, and handle them both right before an
> uninterruptible block ends, and again right after it ends.
> 
> Ok so not such a great idea.

In terms of an API for signal queuing, I think Tanaka Akira's idea
is elegant and reliable.

-mental