Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:27244 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 42542 invoked by uid 1010); 3 Jan 2007 02:06:47 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 42527 invoked from network); 3 Jan 2007 02:06:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2007 02:06:47 -0000 Authentication-Results: pb1.pair.com header.from=mba2000@ioplex.com; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mba2000@ioplex.com; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain ioplex.com from 66.220.1.142 cause and error) X-PHP-List-Original-Sender: mba2000@ioplex.com X-Host-Fingerprint: 66.220.1.142 www.ioplex.com Linux 2.4/2.6 Received: from [66.220.1.142] ([66.220.1.142:2642] helo=www.ioplex.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 24/F2-03249-6BF0B954 for ; Tue, 02 Jan 2007 21:06:47 -0500 Received: from quark.foo.net (c-69-142-196-170.hsd1.nj.comcast.net [69.142.196.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by www.ioplex.com (Postfix) with ESMTP id 0572442B92; Tue, 2 Jan 2007 21:06:43 -0500 (EST) Date: Tue, 2 Jan 2007 21:06:41 -0500 To: "Wojciech Malota" Cc: internals@lists.php.net Message-ID: <20070102210641.06af4197.mba2000@ioplex.com> In-Reply-To: <6A.C8.03249.FD6FA954@pb1.pair.com> References: <20070102122940.662ebd49.mba2000@ioplex.com> <3E.25.03249.EBCAA954@pb1.pair.com> <20070102143627.0c0e6985.mba2000@ioplex.com> <6A.C8.03249.FD6FA954@pb1.pair.com> X-Mailer: Sylpheed version 1.0.6 (GTK+ 1.2.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Semaphores - feature request From: mba2000@ioplex.com (Michael B Allen) On Wed, 3 Jan 2007 01:20:41 +0100 "Wojciech Malota" wrote: > > So the point is that you cannot remove the semaphore when there are no > > callers waiting in semop because that is a perfectly valid state. > > Yes, but if function which acquires a semaphore is constructed as > my_sem_acquire function it will be safe to remove the semaphore when it is > released (if semaphore is "unlocked"). How would your code decide when to actually go ahead and remove the semaphore? Are you suggesting that the semaphore simply be removed whenever it is determined to be "unlocked"? Meaning you want to call semget() and semctl(IPC_RMID) for every single lock/unlock? Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/