From owner-freebsd-current Wed Sep 9 15:35:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA00890 for freebsd-current-outgoing; Wed, 9 Sep 1998 15:35:15 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA00883 for ; Wed, 9 Sep 1998 15:35:11 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id PAA13313; Wed, 9 Sep 1998 15:35:01 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp01.primenet.com, id smtpd013211; Wed Sep 9 15:34:52 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id PAA04517; Wed, 9 Sep 1998 15:34:46 -0700 (MST) From: Terry Lambert Message-Id: <199809092234.PAA04517@usr02.primenet.com> Subject: Re: Thread Problems To: eischen@vigrid.com (Daniel Eischen) Date: Wed, 9 Sep 1998 22:34:46 +0000 (GMT) Cc: info@highwind.com, tlambert@primenet.com, freebsd-current@FreeBSD.ORG In-Reply-To: <199809081933.PAA13564@pcnet1.pcnet.com> from "Daniel Eischen" at Sep 8, 98 03:33:19 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > That is it. The application SITS idle right here. Doing NOTHING. It > > > will respond to additional connections. So, it appears that the > > > "accept()" thread is still responsive. However, all other threads are > > > not responsive. > > > > You are aware of the fact the socket options are not inherited > > across a dup, dup2, fcntl( ..., F_DUPFD, ...), connect, accept, > > bind, etc., right? > > The threads library makes the files non-blocking. He's doing an > accept on a listen socket that the threads library should have > made (and did, because it works the first time) non-blocking. > The socket should have been made non-blocking when it was made > by the wrapped socket() call. > > dup, dup2, connect, accept, and bind are all wrapped by the threads > library and should result in non-blocking files also. > > It does seem that the listen socket somehow became blocking, > but it isn't apparent by looking at the code. Is a > fcntl(fd, F_SETFL, O_NONBLOCK) sufficient to set a socket > non-blocking across multiple accepts? No. You are getting confused here between the non-blocking flag on the actual fd, and the non-blocking flag maintained in user space threading to determine how a call should be multiplexed. That is, if a socket is created via socket(3) (the threads library socket(3) is a wrapper for socket(2)), the socket(2) socket will be non-blocking, but the socket(3) socket will be "blocking" (that is, a call to it will block the thread making the call until the call can be completed successfully). This is the difference between "blocking th thread" and "blocking the process". If a "blocking" call is made (i.e., a call on a "blocking" fd, from the thread's perspective), then it will block. The socket option inheritance issue applies to the inheritance of user space flags, as well, which I don't think the threads library successfully wraps. If the server code expects the "non-blocking" flag, as set within the context of a thread, so that the call will not result in a threads context switch, to be non-blocking after derivation from another socket where the flag was set, then this could be the problem. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message