Re: [Chicken-hackers] PATCH Re: slow polling

[Jörg F . Wittenberger]

I can only repeat: the all-in-one change did not fly neither will the
piecemeal approach.

We need to come up with a small API atop of which users can switch
scheduler implementations.

Am 20.05.2016 um 21:26 schrieb Peter Bex:
> On Fri, Feb 19, 2016 at 10:39:23PM +0100, Jörg F. Wittenberger wrote:
>> A "Betthupferl" is Bavarian (a German dialect spoken in some remote,
>> hilly areas) for the last, small mean given to the kids upon bedtime.
>> Contradictory to all teachings often a sweet.
>>
>> This patch is not supposed to do any harm.
>>
>> It refactors parts of the code to minimize the upcoming diffs.
>> Furthermore it basically takes srfi-18 out of the equation.  Only
>> whitespace/comment diffs left there.
> 
> I had a look at this patch, but it does too much and too little at the
> same time:
> 
> - The moving of unblock-threads-for-timeout is a good change, but it
>    should be a separate commit.
> - You define fdset-clear as a no-op, so unless I'm missing something, it
>    will never ever remove the underlying file descriptors from the sets,
>    even if the fd is closed.  This is a recipe for disaster.

Can't say much about that anymore.  This code was written about 8 years
ago.  At that time it did work.  And it did so under a load which does
apparently stress chicken's i/o more than any other.  But hey, this was
tested on Linux only, ages ago.  Sure it's no proof.

> - Even if fdset-clear wasn't a no-op, this commit would be incompatible
>    with select(), which is the reason we tear down and recreate the fdset
>    from fd-list every time.  I am aware it's not very efficient (and I'd
>    even admit to it being "brain dead" as you call it), but the way
>    select() works is that it will mutate the input set in-place, so you
>    can't rely on it maintaining a consistent state.  POSIX poll() is
>    better designed in almost every way imagineable, but we do have to
>    deal with the shit show that is Windows.  To keep things sane we do
>    it in one consistent way for both select() and poll(), instead of
>    having two code paths to maintain in code that is already very hairy.
> 
> I'll have to think about this, maybe we can come up with a way to avoid
> paying the price on UNIX for the shit Windows implementation.  Better
> would be to have a *proper* implementation on Windows, but nobody has
> stepped up to actually overhaul the entire code to make that possible,
> so far.
> 
> Cheers,
> Peter
>