From owner-freebsd-smp Fri Apr 9 17:52:30 1999 Delivered-To: freebsd-smp@freebsd.org Received: from smtp01.primenet.com (smtp01.primenet.com [206.165.6.131]) by hub.freebsd.org (Postfix) with ESMTP id DC46D14FD2 for ; Fri, 9 Apr 1999 17:52:23 -0700 (PDT) (envelope-from tlambert@usr01.primenet.com) Received: (from daemon@localhost) by smtp01.primenet.com (8.8.8/8.8.8) id RAA22307; Fri, 9 Apr 1999 17:50:11 -0700 (MST) Received: from usr01.primenet.com(206.165.6.201) via SMTP by smtp01.primenet.com, id smtpd022296; Fri Apr 9 17:50:06 1999 Received: (from tlambert@localhost) by usr01.primenet.com (8.8.5/8.8.5) id RAA06066; Fri, 9 Apr 1999 17:50:04 -0700 (MST) From: Terry Lambert Message-Id: <199904100050.RAA06066@usr01.primenet.com> Subject: Re: concurrent select()s on listen socket broken under SMP To: barney@databus.com (Barney Wolff) Date: Sat, 10 Apr 1999 00:50:04 +0000 (GMT) Cc: smp@FreeBSD.ORG In-Reply-To: <370d8a8b0.4bf5@databus.databus.com> from "Barney Wolff" at Apr 9, 99 00:35:00 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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