Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:27246 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5343 invoked by uid 1010); 3 Jan 2007 06:37:32 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 5328 invoked from network); 3 Jan 2007 06:37:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2007 06:37:32 -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:3216] helo=www.ioplex.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E8/C3-13873-B2F4B954 for ; Wed, 03 Jan 2007 01:37:31 -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 B81BB42B92; Wed, 3 Jan 2007 01:37:28 -0500 (EST) Date: Wed, 3 Jan 2007 01:37:18 -0500 To: "Wojciech Malota" Cc: internals@lists.php.net Message-ID: <20070103013718.2810799f.mba2000@ioplex.com> In-Reply-To: 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> <20070102210641.06af4197.mba2000@ioplex.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 06:51:57 +0100 "Wojciech Malota" wrote: > > 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? > > I've wrote about it in my first letter. > There are two functions: my_sem_acquire and my_sem_release. Well I read your original post again. Clearly I've been off track. So the problem is that one process may call semop AFTER another process calls semctl(IPC_RMID) to remove the semaphore from the system? If that's the case then it is still impossible to know if it's ok to remove a semaphore. Only the application would know when all paticipants will no longer need the semaphore and that it can be safely removed. I'm not familiar with the PHP semaphore API but I know a lot about the SysV semphore C api and there's no "FIFO" that could be used to somehow indicate that it's safe to remove a semaphore. You must use some additional application specific logic to trigger semaphore removal. For example you could have a "boss" process that collects the exit status of each "worker". When the boss process has an exit status for all workers the semaphore can be removed. Am I getting closer or am I still not understanding the problem? Mike -- Michael B Allen PHP Active Directory SSO http://www.ioplex.com/