Re: 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. Well they took a simple concept and made it extremly complex. > 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. I like this, but I am wondering if we should perhaps support some of the more advanced capibilities of sysv sems, like support of operation arrays with semop and IPC_PRIVATE, etc. > 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.. That would be great!! -Jason > > 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" <tom.may@infospace.com> > > To: "Chris Chabot" <chabotc@reviewboard.com> > > Cc: <php-dev@lists.php.net>; <php-general@lists.php.net>; > > <jason@inetgurus.net> > > 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 <chabotc@reviewboard.com> 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. > >