Date: Wed, 9 Sep 1998 22:34:46 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: eischen@vigrid.com (Daniel Eischen) Cc: info@highwind.com, tlambert@primenet.com, freebsd-current@FreeBSD.ORG Subject: Re: Thread Problems Message-ID: <199809092234.PAA04517@usr02.primenet.com> In-Reply-To: <199809081933.PAA13564@pcnet1.pcnet.com> from "Daniel Eischen" at Sep 8, 98 03:33:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199809092234.PAA04517>