Date: Tue, 3 Apr 2007 14:46:51 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: jason@hudson-trading.com Cc: freebsd-hackers@freebsd.org Subject: Re: kevent and unix dgram socket problem Message-ID: <20070403144433.F85016@fledge.watson.org> In-Reply-To: <da4a53d80704030510r32aa98eek4e7b01fb781ea205@mail.gmail.com> References: <da4a53d80704030510r32aa98eek4e7b01fb781ea205@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 3 Apr 2007, Jason Carroll wrote: > // create the local address, bind & listen > struct sockaddr_un addr; > memset(&addr, 0, sizeof(addr)); > addr.sun_family = AF_LOCAL; > strncpy(addr.sun_path, "usock", UN_PATH_LEN - 1); > assert(bind(fd, (sockaddr*) &addr, sizeof(sockaddr_un)) == 0); > assert(listen(fd, LISTENQ) == 0); Try dropping the listen() call. This is only required for stream sockets where you will then accept() new connections (returning new sockets). listen() should probably be returning an error, and apparently isn't. What may be happening is that as of the point where listen() is called, future attempts to register kevents for "read" will be set up to detect whether accept() will return a socket or not, not whether there is data in the socket listen() has been called on. I'll investigate adding a check so that an error would have been returned here. This relates to another bug we have, in which if you register a kqueue event for "read" on a TCP socket before calling listen(), then the result is very different from what happens if you register the kqueue event after listen(). Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070403144433.F85016>