Re: threads package status

Uzytkownik "Wez Furlong" <kingwez@gmail.com> napisal w wiadomosci news:4e89b42604071916505f859668@mail.gmail.com... > proc_open() > stream_select() > > No forks, no threads; you don't really need them. > > Have a master process spawn a number of worker processes via > proc_open(), creating pipes to each. > > Each worker waits for a packet to come in on its stdin pipe, does some > processing and then writes to stdout that it is complete. > > Master listens to stdout of all processes to collect the results (it > can also manage "RPC" in this way and feed more data to a particular > process), and then assign jobs to ready workers by stream_select()ing > on their stdin pipes. > > Best thing about this technique is that it is portable to OS's that > don't have fork(), and works in non-threaded builds of PHP. hmmm... ok, this solution is interesting, but i still see one problem. code isnt shared - every process has to compile (the same!) components on its own. i wanted to avoid it. some crucial components (ie. message manager) have to be placed in shared memory. my idea would seem to be perfect application of low complexity threading - i needed just separate 'instruction pointer' for every thread. all data and code should be shared. required synchronization: one global mutex for message queue accessing (which is an PHP array actualy) and one per component to dissallow simultaneus execution based on the same object. have mercy and say i don`t have to do all this process-based workaround ;) rash