From owner-freebsd-smp Thu Apr 8 22: 7:27 1999 Delivered-To: freebsd-smp@freebsd.org Received: from databus.databus.com (databus.databus.com [198.186.154.34]) by hub.freebsd.org (Postfix) with SMTP id ADB1A14ED7 for ; Thu, 8 Apr 1999 22:07:18 -0700 (PDT) (envelope-from barney@databus.databus.com) From: Barney Wolff To: smp@FreeBSD.ORG Date: Fri, 9 Apr 1999 00:35 EDT Subject: Re: concurrent select()s on listen socket broken under SMP Content-Length: 1209 Content-Type: text/plain Message-ID: <370d8a8b0.4bf5@databus.databus.com> Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Different observed behavior UP vs MP does not constitute kernel error, unless the behavior is specifically defined. In this case, select() on the same fd by two processes has no defined behavior, that I'm aware of. (Not that I've done a lot of searching on this topic.) Nor has there ever been any guarantee that a condition discovered by select() will remain true until a subsequent system call. It *usually* does, but that's all. On a very pragmatic basis, if you really can't ever block, set nonblock and be prepared for the occasional cases when the hint given by select doesn't pan out. As someone who first experienced MP bugs in an application over 20 years ago, let me just say that it is a losing cause to count on *undocumented* system behavior staying the same when going from UP to MP. Then again, it's unwise to count on undocumented system behavior, period. Barney Wolff > From: Terry Lambert > Date: Fri, 9 Apr 1999 02:03:33 +0000 (GMT) > > > Seems to me you need to set the socket non-blocking, and then handle > > the EWOULDBLOCK on the fd that loses. I don't think this should be > > considered a kernel error. > > It's SMP specific. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message