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