From owner-freebsd-hackers Thu Feb 11 14:31:14 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA28489 for freebsd-hackers-outgoing; Thu, 11 Feb 1999 14:31:14 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA28480 for ; Thu, 11 Feb 1999 14:31:11 -0800 (PST) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id PAA12690; Thu, 11 Feb 1999 15:31:09 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp03.primenet.com, id smtpd012587; Thu Feb 11 15:31:06 1999 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id PAA18042; Thu, 11 Feb 1999 15:30:53 -0700 (MST) From: Terry Lambert Message-Id: <199902112230.PAA18042@usr06.primenet.com> Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com (Matthew Dillon) Date: Thu, 11 Feb 1999 22:30:53 +0000 (GMT) Cc: tlambert@primenet.com, peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG In-Reply-To: <199902112159.NAA95236@apollo.backplane.com> from "Matthew Dillon" at Feb 11, 99 01:59:52 pm 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-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :What about a negative initial value setting? > > What does POSIX have to say about it? Uh, it doesn't specifically disallow it. The POSIX RT stuff apparently deprecates the IPC interfaces (according to the Go Solo2 CDROM). The POSIX RT stuff doesn't allow for negative values (the semaphore value in semaphore.h is an unsigned int), but the semctl SETVAL operation does allow a negative number. In the strictest sense, I guess that my use has been deprecated: The POSIX Realtime Extension defines alternative interfaces for interprocess communication. Application developers who need to use IPC should design their applications so that modules using the IPC routines described in _IPC_ can be easily modified to use the alternative interfaces. I guess that this technically means that I should use two semaphores instead of one to implement the interlock (that's what I had to do on FreeBSD). Seems... inelegant, somehow. At the very least, it takes a lot more work to deal with client dropout. Ugh. The new interfaces aren't counting semaphores. That means that I'd need yet another semaphore to acquire the right to use the RPC mechanism. Bletcherous. Hm. On the old interfaces, there's nothing that says a negative semadj value, or one larger than sem_cnt, *isn't* allowed to happen... Go to the other (-1) example. My example is obviously abuse under the portability "should", even though it works on AIX, Solaris, SunOS, Dell UNIX, and UnixWare (they all share source code there, so that's not a surprise). If someone else is flagellating them negative, you could probably defend it not working. 8-(. 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-hackers" in the body of the message