Re: threads package status
| From: | Robert Janeczek | 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