chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] [PATCH] Avoid context switch during TCP errno repo


From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Avoid context switch during TCP errno reporting
Date: Wed, 27 Mar 2013 00:19:36 +0100
User-agent: Mutt/1.4.2.3i

On Thu, Mar 21, 2013 at 07:13:46PM +0100, Jörg F. Wittenberger wrote:
> On Mar 20 2013, Peter Bex wrote:
> >Do you think you could post a clean patch for introducing just this one
> >change to tcp?  That would be great.  I'd have to dig in otherwise,
> >anyway since I'd like to change tcp to avoid using select().
> 
> I'm afraid this is not completely possible.
> 
> So far I did not bother to provide /true/ READY? procedures
> for the input ports.  Instead they return #t until the port is
> closed.  (I don't have any use for this test. Instead of testing
> whether or not the read would block I use to just read along
> and have the thread blocked if needed.)
> 
> Doing a real READY? procedure is IMHO not going to work without
> a single-fd poll.

This is true.  The ioctl suggested by Florian doesn't work for
tcp-accept-ready?; it only returns 1 when there's actual data to
read, not when the fd is in a ready state.  I'm also unsure how
portable it is.  OTOH, Windows does seem to know about it...
Anyway, using poll()/select() avoids these issues.

> Otherwise find the modifications attached.

Thanks for the patch!  I've cleaned it up a little bit:  Your patch
introduced an implicit dependency on SRFI-18 through thread-wait-for-i/o!,
which I've now rewritten to use core ##sys#thread-wait-for-i/o! and
##sys#thread-yield procedures.

I also noticed you tried to fix the timeouts by moving the blocking
of the thread to the start before the loop, but I think this would
cause trouble when the thread first gets interrupted on I/O and then
loops again; its timeout value would be cleared upon wakeup, then
it would loop, causing it to get stuck.  I moved the calculation itself
to the start but kept the blocking where it was.

Finally, I saw that we were still using select() in a few other places,
in posixunix.scm (in file-select and file-select-one) and in each
char-ready? port procedure through C_char_ready_p().  I've reworked
those to use poll/select depending on what's available here too.

There's only posix's "file-select" left.  I'm not sure what to do
with it.  Probably it needs to be replaced with a select/poll
checking implementation as well.  However, posixwindows doesn't have
an implementation for file-select at all, while select() certainly
is available on Windows (the scheduler uses it too, after all!).

Perhaps we could grab the common stuff and put it in library.scm?
That way, the scheduler and posixunix would be re-using the same code,
eliminating potential bugs due to the difference.  We could even
replace the select() implementation with a more "native" system for
Windows (whatever that would be) once we've done this.  What do y'all
think?

Anyway, here's the (preliminary) patch.

Cheers,
Peter
-- 
http://www.more-magic.net

Attachment: 0001-Replace-select-by-poll-when-available-in-char-ready-.patch
Description: Text document


reply via email to

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