Re: Re: Re: sysvsem extention question

----- Original Message ----- From: "Chris Chabot" <chabotc@reviewboard.com> To: "Jason Greene" <jason@inetgurus.net> Cc: "Sascha Schumann" <sascha@schumann.cx>; "Tom May" <tom.may@infospace.com>; <php-dev@lists.php.net>; <php-general@lists.php.net> Sent: Friday, August 24, 2001 11:30 AM Subject: Re: [PHP-DEV] Re: Re: sysvsem extention question > 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.. That should work the same as the 3 semaphore method. The thing I wonder is if the module should do this, or if this should be left up to the php programmer. I would suggest getting as close to the C API as possible, with the possibility of adding some easier to use functions. I am starting to think that any other method would be very unflexable. -Jason > 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 > > > >