Re: [naviserver-devel] commit/naviserver: gustafn: - Fix to prevent multiple DriverAccepts on the same socket. The original coded relied on the fact that later accepts

[Gustaf N. <ne...@wu...>]

Cool, good guess, but it did not help - but the proposed
change should go into the repository.

Not surpisingly, the hang happens only when (acceptsize > 1) ....

But, i got that sucker: In the following ioctl (and others
maybe as well) the "long" is wrong, since linux expects
there an int.  That's why we see the problem with 64bit
machines and on bsd!

========================================
int
Ns_SockSetNonBlocking(SOCKET sock)
{
     unsigned long nb = 1;
     if (ns_sockioctl(sock, FIONBIO, &nb) == -1) {
         return NS_ERROR;
     }
     return NS_OK;
}
========================================

Interestingly OpenBSD and linux

    http://www.rootr.net/man/man/ioctl/2
    http://linux.die.net/man/2/ioctl_list

list the type as "int",
while e.g. mks wants a "long"

    http://www.mkssoftware.com/docs/man5/sockets.5.asp

Does anyone know, how to figure out, on which platforms
the long is wanted? The majority seems to be "int".

-gustaf

Am 12.04.10 16:03, schrieb Stephen Deasey:
> On Mon, Apr 12, 2010 at 2:33 PM, Gustaf Neumann<ne...@wu...>  wrote:
>    
>> Without the patch naviserver hangs (blocks) on that machine already
>> at the first or second request.
>>      
>
> This should never happen as the listen socket is set to non-blocking mode, here:
>
>    http://bitbucket.org/naviserver/naviserver/src/tip/nssock/nssock.c#cl-131
>
> nssock.c:Accept() calls nsd/sock.c:Ns_SockAccept() which calls
> accept(2), who's man page says:
>
>      If no pending connections are present on the queue, and the socket
> is not marked
>      as non-blocking, accept() blocks the caller until a connection is
> present.  If the socket
>      is marked non-blocking and no pending connections are present on
> the queue, accept()
>      fails with the error EAGAIN or EWOULDBLOCK.
>
> In which case, Ns_SockAccept looks wrong:
>
> SOCKET
> Ns_SockAccept(SOCKET lsock, struct sockaddr *saPtr, int *lenPtr)
> {
>      SOCKET sock;
>
>      sock = accept(lsock, saPtr, (socklen_t *) lenPtr);
>
>      if (sock != INVALID_SOCKET) {
>          sock = SockSetup(sock);
>      }
>
>      return sock;
> }
>
>
> Shouldn't this be something more like:
>
>      if (sock>  -1) {
>          sock = SockSetup(sock);
>      }
>
> as INVALID_SOCKET is -1 but there is more than one possible error state?
>
> (I haven't tried this...)
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> naviserver-devel mailing list
> nav...@li...
> https://lists.sourceforge.net/lists/listinfo/naviserver-devel
>    


-- 
Univ.Prof. Dr. Gustaf Neumann
Institute of Information Systems and New Media
WU Vienna
Augasse 2-6, A-1090 Vienna, AUSTRIA