On 2/10/07, Michael A. Cleverly <[EMAIL PROTECTED]> 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


Reply via email to