[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] PATCH Re: slow polling
From: |
Jörg F . Wittenberger |
Subject: |
Re: [Chicken-hackers] PATCH Re: slow polling |
Date: |
Mon, 23 May 2016 11:14:08 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux armv7l; rv:38.0) Gecko/20100101 Icedove/38.4.0 |
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
>