Re: threads package status

From: Date: Mon, 19 Jul 2004 23:30:59 +0000
Subject: Re: threads package status
References: 1 2 3 4  Groups: php.pecl.dev 
Request: Send a blank email to pecl-dev+get-989@lists.php.net to get a copy of this message
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 :] > In PEAR (our lovely repository) > there is > Net_Server package. It includes "server" that does preforking - example how to fork. i use this package for request listening, so i`m quite familiar with its capabilities, but as written above - i need windows too. > 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 [httpd+php module] runs for every request simple php script that connects to application server (started earlier by cli) passing http data to it. [application server] using passed parameters puts proper messages in queue allowing threads to process them. messages are actualy callbacks in different components that are able to comunicate using the same queue as main app server. as you probably see - without threads in app server one component can freeze not only one session (request), but the entire processing. even assuming nice written components that are fast and unhangable - one component waiting for data (from db for example) freezes everything. i assumed that most of the requests will not require changing of components data, so component-level cache will probably give massive speedup, but one can`t benefit from this when whole server waits for 10MB mysql query result. or even worse - using web service to fetch one byte response from the other side of the globe, because i want to implement (semi)transparent distributed components. 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 ;) rash

« previous php.pecl.dev (#989) next »