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, 20 Mar 2013 21:42:53 +0100
User-agent: Mutt/1.4.2.3i

On Wed, Mar 20, 2013 at 08:12:18PM +0100, Jörg F. Wittenberger wrote:
> Not at all.  I forgot to mention: it relies only on
> ##sys#thread-block-for-i/o! 
> and skips the single-fd ##net#select-write stuff entirely
> for the sake of fairer scheduling.
> 
> >I'll need some time to dig in and see why this is being done and
> >if we need to replace the select() with poll() like we did in the
> >scheduler or whether the select() stuff can be completely ripped
> >out of the tcp unit, and rely on the scheduler.
> 
> Save your time.  The tcp.scm diff I posted before is in use for
> several month at least.  About as long as my first posting
> to the list under a subject line "poll works somewhat" or alike.
> Since I'm running with poll instead of select.

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

> Unfortunately debugging this heavily threaded and network-i/o
> loaded stuff is really not possible with synthetic tests.
> I can't trigger it at my laptop, whatever I try.  Not even httperf
> will help.  But I can trigger it on an ARM plug, which gets some
> traffic from search engines AND sits behind an customer grade ADSL
> so far.  There it's pretty reliable within a few minutes.

Since you're exposed to the Real Internet, it might just be some
misbehaving client that's producing bad requests which some part of
your (or Chicken's) code does not take into account.  Did you try
sending arbitrary random data to your process, or maybe disconnecting
abruptly?  Maybe try doing an invalid SSL handshake, if that's involved.

You can also put a squid proxy or some other webserver in front of it,
and see if the error persists.  Maybe try Hiawatha; it has logging
options to detect misbehaving clients (potential attacks).  Once you
know what type of invalid requests are sent you can try synthetic
tests that reproduce those requests and debug your program.

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



reply via email to

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