Re: Re: Re: sysvsem extention question

From: Date: Fri, 24 Aug 2001 16:30:12 +0000
Subject: Re: Re: Re: sysvsem extention question
References: 1 2  Groups: php.dev php.general 
Request: Send a blank email to php-dev+get-64255@lists.php.net to get a copy of this message
Hey Jason, i do see your point. However, something still illudes me in my reasoning i think.. In a web envirioment, you are most likely to be in one of two situations when using semaphores. - Plain standard lock (with ability of doing resource count) - All web servers connect to a external process that handles a service (like printer) - The web processes them selves are the 'external resource' which handle the decreasing of lock-count The notes in the original source code of the php extention explained that the second+third lock were used for: - Resource count - Be able to set initial max-resource count However, when i follow this reasoning, two things come to mind - Resource count is a API provided by the sysvsem implimentation via semctl (# waiting, etc) - if you try to set the semaphore's resource count, and it fails (other process connected to it and locked it?) then wouldnt it be safe to assume that that 'other process' is another web process, which sets the same resource counters... so we end up with an good situation anyways... So if you would do a semget with IPC_CREATE + IPC_EXCL. If this succeeds, do the SETALL/SETVAL routine via semctl, if it fails on EEXISTS, do a second semget without create+excl and attach to it.. Donno if it would work, or how-much overhead it would add, but it sounds like it could ;-) -- Chris Jason Greene wrote: > ----- Original Message ----- > From: "Sascha Schumann" <sascha@schumann.cx> > To: "Jason T.Greene" <jason@inetgurus.net> > Cc: "Tom May" <tom.may@infospace.com>; "Chris Chabot" > <chabotc@reviewboard.com>; <php-dev@lists.php.net>; > <php-general@lists.php.net> > Sent: Friday, August 24, 2001 1:49 AM > Subject: Re: [PHP-DEV] Re: Re: sysvsem extention question > > > > parent process right before fork. There is no parent > > > initializer for a php module author > > > > MINIT() is called from the parent process in forking servers. > > The mm storage handler uses this hook to instantiate a shared > > memory segment and propagate the handle to all child > > processes. > Sascha is right... > Allow me to reword.. > There is no way to allow a php file author the ability to execute php source during > module startup of a forking web server. The module would have to allocate and > initialize all semaphores before the php source is parsed. This defeats the purpose > of a semaphore extension in a forking webserver environment, becuase the php source > author would be limited to just the semaphors allocated by the php module. > > -Jason > > > - Sascha Experience IRCG > > http://schumann.cx/ > > http://schumann.cx/ircg > >

« previous php.dev (#64255) next »