Re: Changeset 0306c5a64775

On 2012-01-08, Will Noble <[email protected]> wrote:

> 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.

Would a counter be sufficient for this?  I see some use of weak
pointers in scheme/posix/signal.scm, so I really have no idea whether
we could safely use that optimization (i.e. look at a counter instead
of the thread queues themselves), even if we didn't need a more
general solution.


Robert Ransom