Ok, I tried to use semaphores between php and C++. Where the php script was the client and the C++ app was a server. Client only acquired sems, server only released. This cannot be done with php semaphores. Got around the first two problems: 1) Php semaphore is actually 3 sysV sems. a. Need to have the C++ program create one with 3 2) Php will reset sem 0 - the real sem whenever sem_get() is done. a. Sem 1 is a "reference count" - number of procs using it, and sem 2 is used to lock access to sem 1. b. Ok, so made C++ set sem 1 to 1. Actually since I know it starts 1st I just blindly do that. For some odd reason, it seems that sem 2 also needs to be set to 0... not sure why. The right way would be to wait till sem 2 is 0, then check if sem 1 > 0. If so, increment it and do not init sem0. Else, set sem 0 to init value, set sem 1 to 1 and set sem 2 back to 0. However, could not get past the problem that php always sets the UNDO flag. So, when the script exits, the semaphore is reset. That completely messes up the client/server approach. Another amusing note is that the C code that php uses to implement the semaphores uses the "wait-for-zero" feature of sysv semaphores. Kind of funny that it was seen as needed for even that little effort, but not exposed in php itself J Not to mention all of the other features... So... then. Switch to signals. But to do that correctly, I use a semaphore. In the signal handler, it releases the semaphore. When waiting for a signal in the main loop, I do an acquire. Then.... I find out that sem_acquire() actually returns **OK** when the underlying semop call gets an EINTR!!! Holy cow. How can a "php system" call loose an error?! That's just crazy. I do find it interesting that it's not discussed more on the list... but semaphores are kind of silly in php. Jeremy
