From owner-freebsd-current Thu Sep 10 12:04:40 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA00475 for freebsd-current-outgoing; Thu, 10 Sep 1998 12:04:40 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from relay.mail.pipex.net (relay.mail.pipex.net [158.43.128.38]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id MAA00466 for ; Thu, 10 Sep 1998 12:04:32 -0700 (PDT) (envelope-from james.g.mansion@hsbcgroup.com) From: james.g.mansion@hsbcgroup.com Received: (qmail 11680 invoked from network); 10 Sep 1998 17:02:32 -0000 Received: from unknown (HELO hbmdtemime1.hsbcgroup.com) (193.129.96.77) by iprelay.mail.pipex.net with SMTP; 10 Sep 1998 17:02:32 -0000 Received: from hbmdtemime2.tex.hsbcmidland.com (unverified [128.4.110.202]) by hbmdtemime1.hsbcgroup.com (Integralis SMTPRS 2.0.15) with ESMTP id for ; Thu, 10 Sep 1998 17:57:53 +0100 Received: from hbmdtesmtp1.tex.hsbcmidland.com (unverified [128.4.110.200]) by hbmdtemime2.tex.hsbcmidland.com (Integralis SMTPRS 2.0.15) with SMTP id ; Thu, 10 Sep 1998 18:00:11 +0100 Received: by hbmdtesmtp1.tex.hsbcmidland.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 8025667B.005DDB86 ; Thu, 10 Sep 1998 18:05:10 +0100 X-Lotus-FromDomain: HSBCMERIDIAN@INTERNET To: HighWind Software Information Cc: freebsd-current@FreeBSD.ORG Message-Id: <8025667B.005D1D44.00@hbmdtesmtp1.tex.hsbcmidland.com> Date: Thu, 10 Sep 1998 18:05:45 +0100 Subject: Re: Thread Problems MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Without wishing to be too catty - why don't you go and read the reference I gave, which has a discussion of this? As I suggested, maybe? You will see that Stevens notes that 'Berkeley-derived implementations do not return the aborted connection to the server, while other implementations should return ECONNABORTED but often return EPROTO instead' Now, maybe we could argue that 'Berkely-derived implementations' are indeed all wrong in their behaviour here. That is probably the point of Stevens' text anyway, though he doesn't use such a strong statement. My copy of the relevant POSIX draft is at home - but then its just a draft and quite old at that. So its arguable whether the behaviour of any particular system is 'correct' or not. I can't check what it has to say about this in the state transition diagrams. Whether or not there is a bug in libc_r is another matter. My point is that this 'problem' of using select and blocking accepts is known, and documented, and the server code needs to be modified to work on Berkely and non-Berkely implementations. Stevens' book cannot be recommended too highly. The second edition is well worth purchasing, even if you already have the first. James HighWind Software Information on 10/09/98 16:43:40 To: James G MANSION/HBMD/HSBCMERIDIAN cc: freebsd-current@FreeBSD.ORG Subject: Re: Thread Problems 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 ********************************************************************** This message originated from the Internet. Its originator may, or may not be who they claim to be, and the information contained herein may, or may not be accurate. ********************************************************************** ************************************************************************ Midland Bank plc, who is regulated in the UK by SFA, has issued the information contained in this message (including any attached documents) for its non-private customers only. It should not be reproduced and/or distributed to any other person. It is not an invitation to buy or sell securities. Opinions may change without notice and members of the HSBC Group may have positions in, or trade in instruments mentioned in this message. Each page attached hereto must also be read in conjunction with any disclaimer which form part of it. ************************************************************************ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message