chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Peter Bex
Subject: Re: [Chicken-hackers] PATCH Re: slow polling
Date: Fri, 20 May 2016 21:26:43 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

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.
- 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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]