From owner-freebsd-hackers Wed Sep 18 19:48:16 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D967D37B401; Wed, 18 Sep 2002 19:48:14 -0700 (PDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 749E143E6A; Wed, 18 Sep 2002 19:48:14 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0424.cvx21-bradley.dialup.earthlink.net ([209.179.193.169] helo=mindspring.com) by falcon.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 17rrMT-0000CO-00; Wed, 18 Sep 2002 19:48:13 -0700 Message-ID: <3D893A36.88EA3C13@mindspring.com> Date: Wed, 18 Sep 2002 19:45:10 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Daniel Eischen , hackers@FreeBSD.org, deischen@FreeBSD.org, Garrett Wollman Subject: Re: sem_init help? References: <20020919005959.GO86737@elvis.mu.org> <20020919015911.GQ86737@elvis.mu.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > now here's the problem, one can basically stick a sem_t into a shared > memory location, then one can share it amongst processes (provided > pshared was set). However there's no requirement that these other > processes do any form of "open" on the sem_t, hence I really have no > way of tracking its usage other than by: > > a) auto-terminating it when the process that did sem_init exits. > b) tracking the page where the actual sem_t was created until either > it is reclaimed via sem_destroy or the page is free'd back to the > OS. > > Unless I'm missing something here. You're safe, but it's not something I would recommend. I thing that sem_t is supposed to be an opaque type (e.g. it could even contain a pointer to a kernel address, after sem_init()). But a strict interpretation would let you get away with not tracking it, if it's in shared memory that's tracked (either by the process, in an mmap(), or by the system, in a System V shared memory segment). Here is the relevent text from sem_destroy(): The sem_destroy() function is used to destroy the unnamed semaphore indicated by sem. Only a semaphore that was created using sem_init() may be destroyed using sem_destroy(); the effect of calling sem_destroy() with a named semaphore is undefined. The effect of subsequent use of the semaphore sem is undefined until sem is re-initialised by another call to sem_init(). I take this "undefined" to mean: "You can implement it so that subsequent accesses are successful, but doing so engourages people to write code that depends on this behaviour, and breaks on implementations where it's not true." IMO, this is the same type of thing that got threads programmers to assume "all threads are processes because Linux threads are effectively processes", and make the design mistakes in their code (the Netscape GIF rendering engine, now corrected, and the recently discussed on -current other code which shall remain nameless, which has not yet been corrected). Encouraging that would be Bad(tm). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message