From owner-freebsd-current Thu Sep 10 08:43:55 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA18699 for freebsd-current-outgoing; Thu, 10 Sep 1998 08:43:55 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from highwind.com (hurricane.highwind.com [209.61.45.50]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA18679 for ; Thu, 10 Sep 1998 08:43:50 -0700 (PDT) (envelope-from info@highwind.com) Received: (from info@localhost) by highwind.com (8.8.6/8.8.6) id LAA17144; Thu, 10 Sep 1998 11:43:40 -0400 (EDT) Date: Thu, 10 Sep 1998 11:43:40 -0400 (EDT) Message-Id: <199809101543.LAA17144@highwind.com> From: HighWind Software Information To: james.g.mansion@hsbcgroup.com CC: freebsd-current@FreeBSD.ORG In-reply-to: <8025667B.003F044A.00@hbmdtesmtp1.tex.hsbcmidland.com> (james.g.mansion@hsbcgroup.com) Subject: Re: Thread Problems Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG The latest edition of Stevens Network Programming has a discussion on this point. The accept should not be done in blocking mode, for exactly the reason suggested below. If you do a blocking accept and the client closes before the connection was complete, accept() should return an error. Then you just loop back into accept again. No harm done. I don't see how this is relevant anyway. The libc_r is supposed to set that fd to non-blocking under the covers. The bug (I believe) is that somehow the fd becomes blocking. I posted a test program that illustrates the problem. See for yourself. -Rob To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message