Re: Changeset 0306c5a64775

On Sat, Jan 07, 2012 at 07:41:27PM +0000, Robert Ransom wrote:
> On 2012-01-07, Michael Sperber <[email protected]> wrote:
> >
> > Robert Ransom <[email protected]> writes:
> >
> >> Before Roderic's patch, waiting-for-external-events? didn't know that
> >> threads which were waiting on the process-id's placeholder were
> >> waiting for an external event, just as it still doesn't know that
> >> threads which are waiting on a signal queue are waiting for an
> >> external event.
> >
> > Why would it have to know that?
> 
> In the process-id case, threads waiting on a process ID's placeholder
> are awakened by process-terminated-children, which is called by the
> os-signal interrupt handler.  Nothing waits on an external-event UID.

I have a slightly different take on this. Deadlock detection occurs in
ROOT-WAIT, which, besides consulting WAITING-FOR-EXTERNAL-EVENTS? also looks
at threads blocking on I/O and (obviously) threads waiting for an alarm.
Each of these three cases corresponds to a type of VM interrupt. So my idea
of what ROOT-WAIT does here is to say that, if we have reason to believe a
VM interrupt might wake a thread, then we don't need to declare deadlock.

What's missing from this picture is OS signals. The VM recognizes OS signals
as a type of interrupt, but ROOT-WAIT doesn't check if anything is waiting
on one. I assumed the reason for this is because, while the run-time system
maintains queues for the other cases, POSIX maintains sole responsibility
for signal-waiters, and RTS doesn't call POSIX.

This suggests to me that the RTS should at least keep track of the number of
threads waiting for a signal, and POSIX could increment/decrement that
number. Then there could be a function WAITING-ON-OS-SIGNAL? that ROOT-WAIT
could check.

Basically, I agree what Robert says, except that I don't think
WAITING-FOR-EXTERNAL-EVENTS? should be extended to deal with things other
than external events (in the narrow sense of the mechanism called "external
events", the one with UIDs). Instead we should just ask "are there any
threads that could wake up if we get an OS signal?" before calling deadlock.

Best,
Will