Date: Fri, 9 Apr 1999 00:35 EDT From: Barney Wolff <barney@databus.com> To: smp@FreeBSD.ORG Subject: Re: concurrent select()s on listen socket broken under SMP Message-ID: <370d8a8b0.4bf5@databus.databus.com>
next in thread | raw e-mail | index | archive | help
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 <barney@databus.com> > From: Terry Lambert <tlambert@primenet.com> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?370d8a8b0.4bf5>