[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 semaphore count lower then zero (0 == locked). This sometimes can be usefull for Client / Server synchonisation. Example
[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 additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators,
[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, 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
