[PHP] sysvsem extention question
I have been playing with the idea of making some application backend
services using pcntl (for singaling and fork)+ sysvsem's (for
synchronisation).
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).
The main this is that a process other then the process that acquired
the semaphore can decrease the semaphore count, thus releasing it for
another client. Another big difference is that a process can set the
semaphore count lower then zero (0 == locked). This sometimes can be
usefull for Client / Server synchonisation.
Example usage for a typical Client / Server program flow using
semaphores / signals :
Server :
create sem
sem acquire
setup envirioment
fork children
Multiple Clients:
repeat (wait for sem acquire) {
send signal to Server
communicate with server, get 'buffer'
process buffer
}
Server:
while (Fill data into buffer) {
semaphore release (!);
Sleep(infinite or untill time out);
}
-> Sleeps untill interupted by signal (signal send by Client/Child)
-> In signal handler:
Send 'buffer' to client that acquired semaphore
return;
will cause the program to go back to main loop, sleep was interupted,
so goes to while (fill buffer) again. Also note that the Client -never-
calls semaphore release. The server does that once the resource is
available again.
Rinse and Repeat till end of time, or end of data :-) This will
distribute the data to be processed over all the different clients
(since semaphores guarantee a linear processing of clients, so all
clients get there equal share).
Last, i don't see why the implimentation as exists, requires 3
semaphores. It all seems kinda kludgy and quick-hack for a specific
project, and not 'sysv semaphores implimented in php'. (please forgive
my rude assumptions)
Does the maintainer (Tom May) want to work on this, or anyone else? I'd
be happy to help out, but my last C coding days are over 6 years behind
me, so i don't feel very confident to lead this project.. So any/all
help and/or comments would be apreciated.
Also i noticed a potential security hole in the exisiting source, at
line 190 of sysvsem.c it uses
semget(key, 3, perm|IPC_CREATE);
However, perm is not zero'd to 7 bits before being used, thus allowing
extra flags being added to the call, which presumably is unintentional,
since it allows nasty flags to be passed to this call. perm is gotton
from arg_perm, which is a lval. What i imagine you 'should' do is zero
out all non-relivant bits, basicly AND perm with 0x777. this will clear
all bits other then the (file style) permission flags.
-- Chris Chabot
Ps. please CC me in replies, since im not subscribed to the php lists.
--
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]
[PHP] Re: sysvsem extention question
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. 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. Man Pages - man pages in linux are avail for: * semget * semop * semctl more info can be found on the url i posted in orig email, it explains the sem api decently. 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.. 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 > > > absolut
[PHP] 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.. 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 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]
