Re: Changeset 0306c5a64775

On 2012-01-05, Michael Sperber <[email protected]> wrote:
>
> Robert Ransom <[email protected]> writes:
>
>> On 2011-12-31, Roderic Morris <[email protected]> wrote:
>>> If I'm looking at the right revision, it's to allow the use of wait()
>>> without triggering deadlock detection
>>
>> It might do that, but it breaks get-address-info from the
>> net-addresses package (which (ab)uses external-event UIDs in the same
>> way).
>
> Not quite: In `net-addresses', the external event is indeed triggered
> from the external code, which is not the case with the waitpid stuff,
> which just trampolines into the external events from Scheme.  So I
> believe the solution is to do with the wait code as with the getaddrinfo
> case, namely to wait in a separate thread (or revert to the old
> implementation if threads are not available.)  I'll look into doing this
> over the weekend.

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.

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.


Robert Ransom