[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 > > > absolute lock). > > > > A lock is just a degenerate case. A slightly less degenerate case > > (that can't be implemented with flock) is when you want to allow N > > users of the resource instead of just one. > > > > > 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 >
[PHP] Re: sysvsem extention question
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 want to allow N
> users of the resource instead of just one.
>
> > 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 :
>
> I admit I haven't looked at this hard enough to understand all the
> details, but could message queues help you out here? You could get
> higher throughput since the server fills the buffer and calls msgsnd()
> beforehand, whereas in your signalling implementation clients will
> stall between the time they signal the server and the time the server
> has filled a buffer for them. Also, you need some additional overhead
> to manage the buffer handoff from client to server. And doing things
> in signal handlers can get dicey.
>
> If a message queue isn't big enough for you, you can pass references
> to shared memory in your messages.
>
> > 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.
>
> I don't remember why either. I did that code somewhere around the end
> of 1998 . . .
>
> > It all seems kinda kludgy and quick-hack for a specific
> > project, and not 'sysv semaphores implimented in php'. (please forgive
> > my rude assumptions)
>
> Bingo.
>
> > Does the maintainer (Tom May) want to work on this,
[PHP] 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 want to allow N
users of the resource instead of just one.
> 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 :
I admit I haven't looked at this hard enough to understand all the
details, but could message queues help you out here? You could get
higher throughput since the server fills the buffer and calls msgsnd()
beforehand, whereas in your signalling implementation clients will
stall between the time they signal the server and the time the server
has filled a buffer for them. Also, you need some additional overhead
to manage the buffer handoff from client to server. And doing things
in signal handlers can get dicey.
If a message queue isn't big enough for you, you can pass references
to shared memory in your messages.
> 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.
I don't remember why either. I did that code somewhere around the end
of 1998 . . .
> It all seems kinda kludgy and quick-hack for a specific
> project, and not 'sysv semaphores implimented in php'. (please forgive
> my rude assumptions)
Bingo.
> 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.
I no longer use php or maintain any of the stuff I helped with (aside
from answering the occaisional question, like this one.
> 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.
AND with 0777. Good catch.
> -- Chris Chabot
>
> Ps. please CC me in replies, since im not subscribed to the php lists.
Me either.
Tom.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For
