Re: [Chicken-hackers] slow polling

[Jörg F . Wittenberger]

Am 21.02.2016 um 19:52 schrieb Peter Bex:
> On Sun, Feb 21, 2016 at 07:43:06PM +0100, Jörg F. Wittenberger wrote:
>> Hi folks,
>>
>> IMHO the patch in
>> http://lists.nongnu.org/archive/html/chicken-hackers/2016-02/msg00032.html
>> SHOULD be applied - it fixes a serious bug.
> 
> This is a very invasive change.  Do you have a test case that shows
> how this breaks?

In practice: yes I do.  Right here.[1]

Now this is not a proof.

However I don't know yet how to produce a simple test case.

The problem is that we'd need to force the signal to be delivered during
poll/select.

How would I write a test which does?



Alternatively we may try to _understand_ what the code is going to do
and what it is supposed to do.

What we need to do is: restart the poll/select/sleep after handling the
signal. The latter is done in the forced gc. The former by the loop in
##sys#schedule.

What forcing the primordial is going to to is easy to see: it will
continue with the procedure stored in slot 1 of the primordial thread.
Whatever that is.[1]  Doing so is obviously often wrong.

Now there is IMHO no point in going after those cases. The important
question is: what is this primordial thread supposed to do at this
point?  I simply don't see _any_ reason to unleash it.  But I understand
that unleashing it is doing damage.

Just try disabling (try the simple path - make ##sys#force-primordial to
do nothing) and test.  I could not find any damage.


Cheers

/Jörg

[1]  My app runs for a while and then segfaults. When I enable "dbg" in
scheduler.scm (or - as I did to verify that this is the problem - have a
"dbg2" doing the same but use it only for the case where polling returns
-1) I see this being the last thing before segfault.

[2] Blocked on mutex or condition variable -> blow through (always
wrong), sitting in thread-join! -> depends on thread state, may blow
though, block again without doing anything else (the only good case) or
in raise exceptions for 'ready' and 'running'.  (In my case the
primordial sits in thread-join! and the joined thread _may_ be active,
though I did not try to follow how it actually came to the segfault.)
For blocking in i/o I did not check.