Re: Changeset 0306c5a64775

I actually quite like the approach Robert's patches take. It has the
advantage of expedience in this case, as it's already implemented and
works well. Moreover, it provides a much more pleasant and useful
interface (and one available in scheme, instead of through the FFI)
than the UID approach, which seems to be broken in the general case.

Will might be right in his thinking, but there's still the matter of
library writers, outside of the libraries that are included in s48,
that need to avoid deadlock when waiting on say, work being done in a
separate pthread. If the UID approach doesn't work in general, why not
give them something like what Robert's written?

-Roderic

On Sat, Jan 7, 2012 at 7:09 PM, Will Noble <[email protected]> wrote:
> 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