Re: threads package status

Robert Janeczek wrote:

Uzytkownik "Andrey Hristov" <php@hristov.com> napisal w wiadomosci news:40FC6986.1030901@hristov.com...

Isn't it possible to use fork() (sorry but only *nix).

i need a solution that at least seems to be working on windows also :] hmmm....

i use this package for request listening, so i`m quite familiar with its capabilities, but as written above - i need windows too. hmm (again :))

Also I think that there in PEAR there is some Fork package. Mutex you can

make by using

ext/sysvsem. For the callbacks ext/sysvshm may help. Also one can use

ext/sysvmsg

for sending messages with "tasks" (i used to implement such a

"distributed" architecture

example (if you are interested I can provide you more information).

the real problem is that i need the threads/processes to cooperate using some global objects. i don`t want to add to much overload for creating threads/processes. main idea is to fetch message (a callback to its processing function to be strict) from queue and run the computations. after finishing computations thread should be able to fetch another callback and run it. let me clear the idea a little bit

I got the idea from the previous message. I am not in the internals of Windows. Maybe Wez can say whether it is possible to prefork processes from a script by using the win32api extension, but after then you have problem with the shared memory. well there is a way to have shared memory and semaphores (emulated) under windows - ext/shmop. it's for shared memory but semaphores are easy to implement by using shared memory (i have working code for that). Important is that under windows shmop does not work under cli/cgi due to the nature of creating the shared memory by using memory mapped file (or something like this, i remember Ilia Alshanetsky telling me something like that). Therefore your app server has to run inside apache - preforking won't work except you start some kind of script that makes requests to the server and the closes the connection. The scripts (worker threads) inside the server won't output anything and should not be terminated because of the terminated connection (there is a way to do that). Then you have your threads waiting and they communicate with their master throught ext/shmop. What do you think? (the ideas here were developed on the fly)/

speed is crucial and messages processing mostly requires too few operations to justify new process creation and additional time for ipc. i know - its all in java - i don`t care ;) it's all in PHP under linux/bsd :)

rash

andrey