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
0001-use-separate-ports-for-subsequent-tests-in-the-perf-.patch
Description: Binary data
On 21/09/2011, at 03:07 , Christian Grothoff wrote: > Dear Will, > > This is great news, I'll try the patch ASAP. Two remarks though: > > 1) the tests were never intended to really test the SO_REUSEADDR behavior -- > if you change the port numbers to be disjoint between runs, this should help. > You are right that on Linux the TIME_WAIT is avoided (for loopback!) whereas > other systems are a bit more picky, so the tests should be changed to not > rely on this behavior. > > 2) SIGPIPE is supposed to be managed by the application; MHD as a library > should not install signal handlers IMO. So this is not a bug in the MHD > library; however, clearly the testcases *should* install a signal handler > here, again an easy fix. > > So unless your patch breaks stuff on other platforms, this sounds simply > great (and we can trivially fix the issues you mention). > > Happy hacking, > > Christian
