Date: Sat, 10 Apr 1999 00:50:04 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: barney@databus.com (Barney Wolff) Cc: smp@FreeBSD.ORG Subject: Re: concurrent select()s on listen socket broken under SMP Message-ID: <199904100050.RAA06066@usr01.primenet.com> In-Reply-To: <370d8a8b0.4bf5@databus.databus.com> from "Barney Wolff" at Apr 9, 99 00:35:00 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Different observed behavior UP vs MP does not constitute kernel error, If it's the same kernel, it does. If it doesn't, then you aren't talking about symmetry. > 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.) According to Peter, it does. > 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. Yeah, this is as bullshit as signals being persistent conditions instead of events. > 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. This is a way to work around the behaviour in your applications. But if you define a well behaved application as something that has the same 30 lines of code that's in every other well behaved application, then you are starting to get into the realm of something that should be done in a central location, such as the kernel and/or the libc function call wrapper for communicating with the kernel. Unfortunately, there aren't any very good anonymous semaphore mechanisms in FreeBSD , where a semaphore can be given to everyone who is a subprocess of a process group leader, and invisibly enforced by libc. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. 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?199904100050.RAA06066>