From owner-freebsd-hackers Wed Nov 13 18:54:39 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id SAA06872 for hackers-outgoing; Wed, 13 Nov 1996 18:54:39 -0800 (PST) Received: from parkplace.cet.co.jp (parkplace.cet.co.jp [202.32.64.1]) by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA06805 for ; Wed, 13 Nov 1996 18:53:20 -0800 (PST) Received: from localhost (michaelh@localhost) by parkplace.cet.co.jp (8.8.2/CET-v2.1) with SMTP id CAA18346; Thu, 14 Nov 1996 02:52:53 GMT Date: Thu, 14 Nov 1996 11:52:53 +0900 (JST) From: Michael Hancock To: Andrew Stesin cc: FreeBSD Hackers Subject: Re: Programming technique for non-forking servers? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Wed, 13 Nov 1996, Andrew Stesin wrote: > But I have an impression that there's easier > to implement locking of shared memory and file > resources inside a single-process server than > with some kind of IPC. There is SysV IPC around, > but it has it's limitations. Using mmap() as a shared > memory pool? isn't so clear and transparent for me (at least > now), and generally isn't documented; so the question > remains opened, that's why I'm asking about > where a Fine Manual resides which should be read. I read about "4.4BSD" semaphores in the Frontiers book, they were described like this: value = mset(sem, WantMeToBlock); mclear(sem); msleep(sem); mwakeup(sem); You would use mmap to create a shared memory region and use the flag HASSEMAPHORE. mset and mclear would be implemented as lib functions because Intel does have an atomic test and set. A check could be done on the sem without making a system call. These guys don't exist. I wonder where Vahalia got his information from. Regards, Mike