From owner-freebsd-hackers Wed Feb 10 17:38:31 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26144 for freebsd-hackers-outgoing; Wed, 10 Feb 1999 17:38:31 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26135 for ; Wed, 10 Feb 1999 17:38:28 -0800 (PST) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40371>; Thu, 11 Feb 1999 12:27:48 +1100 Date: Thu, 11 Feb 1999 12:38:12 +1100 From: Peter Jeremy Subject: Re: portability of shm, mmap, pipes and socket IPC To: dillon@apollo.backplane.com, tlambert@primenet.com Cc: hackers@FreeBSD.ORG Message-Id: <99Feb11.122748est.40371@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Terry Lambert wrote: >FreeBSD semaphores are inadequately resource tracked in _exit(). Matthew Dillon wrote: > All semaphores are inadequately resource tracked in _exit(), it's a > problem inherited from the SYSV implementation. Could someone please describe what the problem(s) are and what impact they have on applications using SysV semaphores. I have an application (running on 3.0-RELEASE) that relies on the kernel correctly tracking SEM_UNDO's. (Basically I have a wrapper that seizes a semaphore with sem_op = -1, sem_flg = SEM_UNDO and then execs a process that knows nothing about the semaphores.) I was seeing some wierd behaviour, but I thought that was a (now fixed) bug in the kernel handling of SEMUME and SEMUSZ (see PR kern/9068). Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message