Re: Changeset 0306c5a64775

Thanks for looking into this!

Robert Ransom <[email protected]> writes:

> See attached for a bundle which fixes wait-for-child-process.  I'm no
> longer convinced that changeset 0306c5a64775 was wrong, but I think my
> bundle uses a cleaner approach, and it works with the current
> external-event and interrupt systems.

I'm somewhat suspicious of the changes in the bundle, as it's not clear
to me why deadlock should get erroneously signalled before the changes:
After all, there's is special provision to *not* signal deadlock in the
root scheduler - it calls `waiting-for-external-events?', and if that
returns #t, no deadlock is assumed.  (And I still think the right fix is
to handle wait the same as getaddrinfo.)

You've looked at the code in depth - did you consider this?

> When I wrote that, I suspected that part of the problem with
> wait-for-child-process was that it dynamically allocated a new
> external-event UID for each event it wants to wait for, rather than
> using one external-event UID for a whole class of events to be waited
> for.  The PreScheme code to handle external events seems to me to be
> designed for the latter case. [...]

> getaddrinfo also uses a new UID for each event, rather than one UID
> for the whole class of getaddrinfo-completion events; I still suspect
> that that is why multiple simultaneous calls to wait-for-child-process
> broke a later call to getaddrinfo.

It was designed for both cases, but in fact the getaddrinfo code was the
original motivation for implementing it.  It's needed there because
there may be multiple simultaneous active calls to getaddrinfo from
different threads, and they all need to be notified separately of
completion.

So, if that doesn't work correctly, there's a bug.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla