----- Original Message -----
From: "Chris Chabot" <[EMAIL PROTECTED]>
To: "Jason Greene" <[EMAIL PROTECTED]>
Cc: "Sascha Schumann" <[EMAIL PROTECTED]>; "Tom May" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
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" <[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
> > >
>
--
PHP Development 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]
