Re: [naviserver-devel] OpenBSD/sparc64: driver blocks on a new connection if acceptsize > 1

[Stephen D. <sd...@gm...>]

On 2/10/07, Michael A. Cleverly <cle...@gm...> wrote:
> My adventures (with CVS HEAD) on OpenBSD/sparc64 continue.
>
> Unless I set:
>
>     ns_section      "ns/server/${servername}/module/nssock"
>     ns_param       acceptsize          1
>
> in my conf file then incoming an HTTP request never get serviced
> promptly; I can't connect to the nscp control port, and I can't hit
> CTRL-C to end the (foreground) nsd process.
>
> If I set ns_param acceptsize to 2 then the first connection "hangs",
> when a second one is made both are processed immediately.
>
> The default acceptsize is equal to the backlog setting, which defaults
> to 256.  I strongly suspect (but haven't had the patience to confirm)
> that with no acceptsize setting I'd have to have 256 active HTTP
> connections before any would be processed at all.
>
> I've sprinkled driver.c, binder.c, and sock.c with caveman debugging
> Ns_Log() calls and it appears to block in the while loop attempting to
> accept more when calling the final check of the four checks [in
> DriverThread() in driver.c at line 1272]:
>
>      (sockPtr = SockAccept(drvPtr)) != NULL
>
> which seems to end up waiting  [in SockAccept() in driver.c at line 1635-6] on:
>
>         sockPtr->sock = Ns_SockAccept(drvPtr->sock,
>                                       (struct sockaddr *) &sockPtr->sa, &slen);
>
> which in turn waits [in Ns_SockAccept() in sock.c at line 420] on:
>
>     sock = accept(lsock, saPtr, (socklen_t *) lenPtr);
>
> which makes me think that the listening socket must not be set in
> non-blocking mode(?).


You could try adding a call to ns_sockioctl() to get the FIONBIO
status of the socket and dump to the log, just to confirm that it
really is set.

It should be -- it works on your other platforms.

Looks like an openbsd-on-sparc bug?

* Either the call to Ns_SetNonBlocking() in driver.c:NsStartDrivers()
is not taking effect
* or the non-blocking status is being dropped after the first call to accept()
* or non-blocking status is being ignored entirely for acept() on
listening sockets. It works the first time because there really is a
connection waiting.



> Suggestions? The same behavior does not occur on OpenBSD 3.8/macppc or
> OpenBSD 3.9/amd64. (Everything works "out-of-the-box" as expected.)
>
> Michael
>