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: Frank Meier
Subject: Re: [libmicrohttpd] shutdown of listen socket does not work on solaris 10
Date: Thu, 22 Sep 2011 16:31:47 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.20) Gecko/20110804 Lightning/1.0b2 Thunderbird/3.1.12

Thanks Guys you saved my day

cheers, Frank

On 21/09/11 10:14, Christian Grothoff wrote:
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]