Re: Changeset 0306c5a64775

On 2012-01-08, Michael Sperber <[email protected]> wrote:
>
> Robert Ransom <[email protected]> writes:
>
>> 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.
>
> Ah, OK, but that's a bug (even documented in the manual) with the signal
> code, which also needs fixing.  As soon as that's fixed, the problem
> goes away, right?

process-id placeholders are separate from signal queues, and their
deadlock-detection issues need to be fixed separately.  (We can't just
use the fix for deadlock detection when threads are waiting on signal
queues to handle the case of process-id placeholders, because
something needs to listen for SIGCHLD all the time, even when no
threads are currently waiting on process-id placeholders.)

>> If the deadlock-detection code isn't told that those synchronization
>> objects will be alerted by (an interrupt handler triggered by) an
>> external event of some sort, then it will falsely report that a
>> deadlock has occurred.
>
> That also makes sense, but if we're talking about "external event of
> some sort", rather than *the* external events (i.e. the specific
> things in scheme/rts/external-event.scm)  then the fix should also
> happen outside of external-event.scm, deeper down in the thread system,
> is my current thinking.  Does that make sense?

It makes sense to keep that mechanism separate from the
external-events package.  See my (revised)
wait-for-child-process-deadlock-fix branch (attached, and pushed using
hg-git to https://git.torproject.org/user/rransom/scheme48.git) for
that.


Robert Ransom