Re: scheduler event-types

On Sun, Jun 19, 2011 at 11:56:51AM -0400, Roderic Morris wrote:
> On Jun 14, 2011, at 6:11 PM, Roderic Morris wrote:
> 
> > I everyone, I'm planning to add a new event-type to s48's scheduling system that would allow users to block without contributing to deadlock detection (for instance, when waiting for an OS signal).

I don't think we need a new thread event type to solve the problem of
waiting for an OS signal tripping the deadlock detection.

Right now you can block on IO, external events, or the alarm clock. Those
comprise three of the five asynchronous VM events. OS signal also belongs
in this category, but unlike the case for the other interrupts the root
scheduler can't know if any thread is waiting on a signal because the
responsible thread queue lives in the POSIX module. The runtime system
can't depend on the POSIX module being available.

At the same time, the POSIX signal system deals with both the numbered OS
signals known to the VM as well as the named POSIX signals, and maintains
a mapping between the two. It maintains signal queues for both kinds
of signals.

This suggests to me that we should move the signal queue system from POSIX
to the runtime, and let POSIX deal only with mapping between numbered
and named signals (for example it could still provide named-signal
queues). Then schedulers can query for the existence of threads waiting
on any kind of asynchronous VM event before giving up and announcing
deadlock.

Regards,
Will