From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 3 13:46:52 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CA78716A402 for ; Tue, 3 Apr 2007 13:46:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 85D6313C43E for ; Tue, 3 Apr 2007 13:46:52 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A23E946EEE; Tue, 3 Apr 2007 09:46:51 -0400 (EDT) Date: Tue, 3 Apr 2007 14:46:51 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: jason@hudson-trading.com In-Reply-To: Message-ID: <20070403144433.F85016@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: kevent and unix dgram socket problem X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2007 13:46:52 -0000 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