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 zer
