libmicrohttpd
[Top][All Lists]
Advanced

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

Re: [libmicrohttpd] shutdown of listen socket does not work on solaris 1


From: Christian Grothoff
Subject: Re: [libmicrohttpd] shutdown of listen socket does not work on solaris 10
Date: Wed, 21 Sep 2011 10:14:27 +0200
User-agent: KMail/1.13.7 (Linux/2.6.39-1-amd64; KDE/4.6.5; x86_64; ; )

Thanks, the patch seems fine (minor fixes and configure-integration are in SVN 
16982), and are commited (SVN 16980, 16981).  

On the OpenIndiana performance, do you have something like 'strace' where you 
could monitor what's going on? Most likely the code hangs blocking in some 
syscall for longer than it should...

As for SIGPIPE, I see why you're on the fence.  But I think the answer is 
simple: for tests where we don't expect a SIGPIPE, we could just put a printf 
into the signal handler that prints a warning.  A good reason for having the 
SIGPIPE code in the tests is that some users might use the testcases as a 
starting point for their own code and might thus be reminded of the need to 
install a handler.

Happy hacking,

Christian

On Wednesday, September 21, 2011 03:01:54 AM Will Bryant wrote:
> Cool.
> 
> So patch attached to use sequential port number assignments in those two
> perf test programs - with that and the earlier pipe shutdown patch, OS X
> passes all tests now.
> 
> OpenIndiana also passes all the perf tests, leaving just the SIGPIPE
> matter.  Incidentally, performance is terrible there.  I would be
> interested to know why - my OpenIndiana box has a modern Intel Q9505 and
> gets in the region of 35 requests/s in each perf test, whereas my aging
> Intel Core 2 Duo macbook gets 600-900 despite having half the cores.  Of
> course we only expect the non-concurrent test to use about 1 of the cores,
> but both that and the concurrent test actually use only about 1% of a
> single CPU.  This is puzzling as OpenIndiana has the very performant and
> scalable sunos/solaris-derived kernel and libc, so something odd is
> definitely going on.
> 
> Regarding the SIGPIPE, do you think a signal handler should be installed in
> all test programs, to implement the recommended behavior for applications,
> or only in those that need it?
> 
> I am sitting on the fence.  I think the argument for the latter would be
> that one would not normally expect SIGPIPE to occur during tests that do
> not test out error/abort behavior, but I don't think it would normally be
> harmful.
> 
> (I haven't implemented the configure script integration to set the
> HAVE_LISTEN_SHUTDOWN conditional define for Linux etc. - can you help
> there?  I have, for what it's worth, checked that Linux does also work
> using the pipe technique instead, so that seems well-portable.)
> 
> Cheers,
> Will



reply via email to

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