Date: Tue, 8 Sep 1998 18:50:17 -0400 (EDT) From: HighWind Software Information <info@highwind.com> To: rotel@indigo.ie Cc: freebsd-current@FreeBSD.ORG Subject: Re: Thread Problems Message-ID: <199809082250.SAA10366@highwind.com> In-Reply-To: <199809082215.XAA01106@indigo.ie> (message from Niall Smart on Tue, 8 Sep 1998 23:15:53 %2B0000)
next in thread | previous in thread | raw e-mail | index | archive | help
> Frankly, this looks like the fd is not async. The only potentially > blocking call should be select(). But it's the thread library's responsability not to call accept until it is sure that the call will not block.... Remember, on the first call to accept(), libc_r WILL make the real accept() call. It'll do it, however, on a non-blocking fd, realize it got a EWOULDBLOCK, and then put the fd on the list for a later accept() once select() fires off. Could fork()/exec() be involved? We do call fork() and exec(). I strongly suspect the fork() or exec() logic might be buggy and since it sets things back to "blocking", it might effect existing fd's. -Rob 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?199809082250.SAA10366>