Re: external events api

On Jul 25, 2011, at 1:49 AM, Marcus Crestani wrote:
> There is a section "External events" in the development version of the
> documentation that describes how to use external events, see
> doc/src/external.tex.

Ahh, thanks, I was looking in 1.8's manual.

> Right, since the uids have to be shared between Scheme and C anyway,
> they could also be created in Scheme and then exported to C.  This
> functionality is currently only in the VM, though.

Ok. I just created some c functions that do only those actions (note, create, or unregister) to make
experimenting with this easier.

I've run into what look like bugs in this API unfortunately. I've tried a few things to try to get
wait-for-child-process to use wait-for-external-events, and most have worked in the simple and most
common case of only one thread waiting on a particular process id, but all have failed for some reason on the
multiple thread case.

In the first one, I tried noting and unregistering a process id's external event uid as soon as the sigchld
came in. That didn't work, and it's reasonable that the external events system would require you to
unregister after all waiting threads are awake.

In the next, I tried having all threads waiting on a given process id wait on one uid that was a field of the
process id. I expected that they'd all be woken up when the uid was noted, but only the first thread to wait
did. I didn't think that was right, but I tried to get around it, and at least get wait-for-child-process working.

For the next implementation, i tried having a process id have a queue of uids which would be added to when a
process waits on it. All the uids in the queue would be noted when the sigchld comes in, and each thread would
unregister the uid it added to the queue. In this case too, only the first thread that waited is woken.

Re: external events api

>>>>>"RM" == Roderic Morris <roderyc <at> gmail.com> writes:
RM> It seems that this api has trouble with notes happening in quick
RM> succession.

Yes, it is not guaranteed that every `s48_note_external_event' gets
handled immediately.  That's why external code has to collect multiple
external events and provide a mechanism for Scheme to obtain *all*
occurred events that have not yet been obtained before.

I took a quick look at your patch and I think you should try the
following:

- In `process-terminated-children' you have to collect all terminated
  children, e.g. put them in a list.

- In `really-wait-for-child-process' you have to obtain that list of
  terminated children after `wait-for-external-event' returns.  Then,
  process every terminated child by unblocking previously called
  `wait-for-child-process', for example via the placeholder in
  process-id.

This way you should not lose any terminated child.

--

-- 
Marcus

Re: external events api

On Aug 3, 2011, at 1:59 PM, Marcus Crestani wrote:

Should've replied to this sooner, but I've been busy. I think we have a misunderstanding.

>>>>>> "RM" == Roderic Morris <roderyc <at> gmail.com> writes:
> RM> It seems that this api has trouble with notes happening in quick
> RM> succession.
> 
> Yes, it is not guaranteed that every `s48_note_external_event' gets
> handled immediately.  That's why external code has to collect multiple
> external events and provide a mechanism for Scheme to obtain *all*
> occurred events that have not yet been obtained before.

I understand that. The problem is that some of those calls are *never* handled. I've left the process idling
for quite a while without them being woken. Moreover, after the first time a thread fails to wake up, all
subsequent calls to s48_note_external_event have no effect, even on brand new event ids.

> I took a quick look at your patch and I think you should try the
> following:
> 
> - In `process-terminated-children' you have to collect all terminated
>  children, e.g. put them in a list.
> 
> - In `really-wait-for-child-process' you have to obtain that list of
>  terminated children after `wait-for-external-event' returns.  Then,
>  process every terminated child by unblocking previously called
>  `wait-for-child-process', for example via the placeholder in
>  process-id.
> 
> This way you should not lose any terminated child.

Re: external events api

Re: external events api

Re: external events api

Roderic Morris <roderyc <at> gmail.com> writes:

> On Aug 3, 2011, at 1:59 PM, Marcus Crestani wrote:
>
> Should've replied to this sooner, but I've been busy. I think we have a misunderstanding.
>
>>>>>>> "RM" == Roderic Morris <roderyc <at> gmail.com> writes:
>> RM> It seems that this api has trouble with notes happening in quick
>> RM> succession.
>> 
>> Yes, it is not guaranteed that every `s48_note_external_event' gets
>> handled immediately.  That's why external code has to collect multiple
>> external events and provide a mechanism for Scheme to obtain *all*
>> occurred events that have not yet been obtained before.
>
> I understand that. The problem is that some of those calls are *never*
> handled. I've left the process idling for quite a while without them
> being woken. Moreover, after the first time a thread fails to wake up,
> all subsequent calls to s48_note_external_event have no effect, even
> on brand new event ids.

Details, please.

--

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

Re: external events api

Re: external events api

Re: external events api

On Aug 13, 2011, at 10:01 AM, Michael Sperber wrote:
> Roderic Morris <roderyc <at> gmail.com> writes:
>> 
>> I understand that. The problem is that some of those calls are *never*
>> handled. I've left the process idling for quite a while without them
>> being woken. Moreover, after the first time a thread fails to wake up,
>> all subsequent calls to s48_note_external_event have no effect, even
>> on brand new event ids.
> 
> Details, please.

I'm not sure what else to say. The patch and example code I gave a couple emails back demonstrate the behavior
I'm talking about, if you'd like a clearer illustration. If the waits are done too close together (and thus
the calls to s48_note_external_event are performed close together), some of the threads are not woken
and sleep indefinitely. Further calls to wait (which end in calls to wait-for-external-event) are never
woken as well.

-Roderic

Re: external events api

Roderic Morris <roderyc <at> gmail.com> writes:

> On Aug 13, 2011, at 10:01 AM, Michael Sperber wrote:
>> Roderic Morris <roderyc <at> gmail.com> writes:
>>> 
>>> I understand that. The problem is that some of those calls are *never*
>>> handled. I've left the process idling for quite a while without them
>>> being woken. Moreover, after the first time a thread fails to wake up,
>>> all subsequent calls to s48_note_external_event have no effect, even
>>> on brand new event ids.
>> 
>> Details, please.
>
> I'm not sure what else to say. The patch and example code I gave a
> couple emails back demonstrate the behavior I'm talking about, if
> you'd like a clearer illustration. If the waits are done too close
> together (and thus the calls to s48_note_external_event are performed
> close together), some of the threads are not woken and sleep
> indefinitely. Further calls to wait (which end in calls to
> wait-for-external-event) are never woken as well.

You mean this, right:

http://article.gmane.org/gmane.lisp.scheme.scheme48/2432

?  Could you send the C code that goes with it?

--

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