Re: [PHP-DEV] Re: Re: sysvsem extention question

[Tom May]

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 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]

Re: [PHP-DEV] Re: Re: sysvsem extention question

[Jason Greene]

- 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]

Re: [PHP-DEV] Re: Re: sysvsem extention question

[Chris Chabot]

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" <[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]

Re: [PHP-DEV] Re: Re: sysvsem extention question

[Jason Greene]

- 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]

Re: [PHP-DEV] Re: Re: sysvsem extention question

[Sascha Schumann]

> 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 Experience IRCG
  http://schumann.cx/http://schumann.cx/ircg


-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

[PHP-DEV] Re: Re: sysvsem extention question

[Jason T . Greene]

> As far as creating the new module goes, it shouldn't be 'to much effort'. The basic 
>implimentation of system v semaphores
> is actualy quite simple, its the usage of sempahores that can be very confusing :-) 
>sysv sem's are often refered to as the
> most difficult to comprehend of the sysv standards.

Well they took a simple concept and made it extremly complex.
 
> I would be more then willing to donate my time and efforts to that project, and i do 
>have some knowledge of how semaphores
> can be used (reader-writer, resource count and lock implimentations). However as i 
>mentioned before, my last C project is
> some years ago, also my knowledge of Zend internals is limited to the php-usage scope
> 
> do note a locked semaphore == 0, any value above 0 allows for a 'lock', this is done 
>to allow multiple client-locks
> clasical example is : if the printer manager daemon has 5 printers, it creates a 
>semaphore with a max_acquire of 5. (so
> acquire count == 5). Every client connecting, lowers that count... untill its zero. 
>Then the client blocks 'till the value
> is positive again.
> 
> Proposed API of the sysvsem
> ---
> 
> * $sem = sem_get($key,$max_acquire,$perms)
>Gets or creates a semaphore id, id is returned in $sem
> * $ret = sem_acquire($sem)
>Tries to lowerer the acquire count of the semaphore. If count is already 0, wait 
>till it is raised (by sem_release) or
> returns an error (sem_remove was called or invalid permission to get semaphore). 
>note: when the client blocks 'semzcnt' is
> increased (semzcnt = # of processes waiting for lock)
> * $ret = sem_release($sem)
> Increases the acquire count
> 
> [proposed new function]
> * $count = sem_get_waiting($sem)
> Returns the amount of processes blocking on a semaphore acquire call. I propose 
>-1 = error, 0 > incicates # of waiting
> processes.

I like this, but I am wondering if we should perhaps support  some of the more 
advanced capibilities of sysv sems, like support of operation arrays with semop and 
IPC_PRIVATE, etc.

 
> Documentation
> --
> I'd be happy to help write up some documentation, general how-to-use semaphores for 
>usage in php docs, plus some example
> implimentations..

That would be great!!


-Jason

> 
> I will see how far i can get using the existing implimentation as a template for 
>implimenting a php module.. however be
> sure i'll come knocking for help fairly soon :-)
> 
> -- Chris
> 
> Jason Greene wrote:
> 
> > There probably should be a full implementation of semaphores in php. If you
> > have a need for this, we should discuss exactly how it should be implemented.
> > I will have some free time available soon, so I can start working on this. Though 
>I have
> > a couple other projects as well. If you would be interested in contributing a CVS
> > account can be arranged. This should probably start as a separate module, and then
> > eventually replace the sysvsem extension as it is no long being actively 
>maintained.
> >
> > I have a great desire for php to function well as a standalone scripting language
> > as well as web, so I am always interested as projects like this.
> >
> > Is there anyone else who would find this useful?
> >
> > -Jason
> >
> > - Original Message -
> > From: "Tom May" <[EMAIL PROTECTED]>
> > To: "Chris Chabot" <[EMAIL PROTECTED]>
> > Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> > Sent: Tuesday, August 21, 2001 1:58 PM
> > Subject: Re: sysvsem extention question
> >
> > > First off, before you get the wrong impression of my answer, let me
> > > say that your observation "It all seems kinda kludgy and quick-hack
> > > for a specific > project, and not 'sysv semaphores implimented in
> > > php'" is right on.
> > >
> > > Chris Chabot <[EMAIL PROTECTED]> writes:
> > >
> > > > I have been playing with the idea of making some application backend
> > > > services using pcntl (for singaling and fork)+ sysvsem's (for
> > > > synchronisation).
> > >
> > > Cool.  But see below.
> > >
> > > > However while reading thru the sysvsem source code, i noticed the
> > > > behaviour of the semaphores in PHP is basicly as a 'lock' (as one would
> > > > use a file lock w/ flock()). From what i understand from my advanced
> > > > unix programming book, and the linux man pages, this is not what
> > > > semaphores are supposed to be (though they can be abused to be so).
> > > >
> > > > The way one would -expect- semaphores to function on a unix platform
> > > > is best described in "Linux Programmers Guide" at
> > > > 
>http://uiarchive.uiuc.edu/mirrors/ftp/ftp.ibiblio.org/pub/Linux/docs/linux-doc-project/programmers-guide/lpg-0.4.pdf
> > > > (page 46 and on).
> > > >
> > > > A short sumary would be: a semaphore is a resource counter (not an
> > > > absolute lock).
> > >
> > > A lock is just a degenerate case.  A slightly less degenerate case
> > > (that can't be implemented with flock) is when you wan

[PHP-DEV] Re: Re: sysvsem extention question

[Jason T . Greene]

> > Last, i don't see why the implementation as exists, requires 3
> > semaphores.

I just looked over the code, and the reason for this is it specifically designed for a 
multi-process web environment. The most common method for semaphore initialization is 
in the parent process right before fork.  There is no parent initializer for a php 
module author, and since each child has its own environment, there is no way to know 
when to initialize the semaphore. 

The way that Tom solved that problem was to create a "USAGE" semaphore which is used 
to insure that the semaphore is only initialized once. There must have been some sort 
of race condition because the purpose of the 3rd semaphore is a lock.

This is actually a sharp way to handle the problem of no central way to initialize.

-Jason



-- 
PHP Development Mailing List 
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]