Chris Chabot <[EMAIL PROTECTED]> writes:
> 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..
I haven't looked at the code for years, but I may have been thinking
that the semaphore lives on after all the processes using it have
died. So, if you change the allowed resource usage in your php code
and restart the server, you want the new value to take effect and not
be stuck with the old value from the last run.
> 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" <[EMAIL PROTECTED]>
> > To: "Jason T.Greene" <[EMAIL PROTECTED]>
> > Cc: "Tom May" <[EMAIL PROTECTED]>; "Chris Chabot" <[EMAIL PROTECTED]>;
><[EMAIL PROTECTED]>;
> > <[EMAIL PROTECTED]>
> > 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
> > >
Tom.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
