Date: Tue, 8 Sep 1998 15:33:19 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: info@highwind.com, tlambert@primenet.com Cc: freebsd-current@FreeBSD.ORG Subject: Re: Thread Problems Message-ID: <199809081933.PAA13564@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
> > 21620 typhoond CALL accept(0x6,0x10afd8,0x10afd4) > > > > 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? Dan Eischen eischen@vigrid.com 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?199809081933.PAA13564>