At 04:29 PM 8/3/2002 +0800, Alan Knowles wrote: >Ok, had a play with this >updated copy on >http://docs.akbkhome.com/threads.tgz > >added a few of pthreads calls to TSRM.c > >did most of the testing without this abstraction layer - just to see if I >could get it to work. > >used php_exectute_script, rather than getting clever and copying the >function/class hashtables.
This was exactly what I suggested a few minutes ago :) >results: > >It worked (with a few caveats - that are just a matter of getting to know >threading better)... > >some of the issues: >-if the child thread finishes before the main one - then the main one >needs to wait somehow.. >** FIX = probably need to keep a count of threads that are running and >block at MSHUTDOWN on the main thread if stuff is still going. >-the child thread needs to have the modules functions loaded before it >starts running really - otherwise you get intermitant 'functions not >available' if you dont dl() the module in the child thread. >** FIX = I need to look at the pthreads equivalant for >tsrm_wait_event(thread.start_event,TSRM_INFINITE); will be.. this should >make sure that the main thread doesnt do anything while the main thread is >starting up.. You should probably make threads a PHP resource and the destructor would wait for the thread to finish. >- php_request_shutdown(NULL); calls the MSHUTDOWN for all modules - a good >example of where this cause trouble is the ext/standard/string.c >MSHUTDOWN, which has a static mutex that is freed. (and would be freed >twice when the main thread finishes) - >hence php_request_shutdown(), probably doesnt want to be called on a >thread completion.. >** FIX = not sure? - does this need fixing or should we just ignore >php_request_shutdown...... I think threads should be treated exactly like a separate request so I think most code could run as is. >due to the nature of thread scheduling, you dont get anything like '1 >opcode from thread A, 1 opcode from thread B', more like about 30-40 >opcodes randomly from each thread.. That's fine. Andi -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
