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. 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.. - 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...... 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.. regards alan Shane Caraveo wrote: > Here is a *very* rough peice of code for starting a thread. It should > get across the idea of how I am thinking threads need to be started, > but it doesn't work (I haven't even tried to run it). More > importantly though, as a starter, is getting an api into TSRM that > will support the abstraction of any thread calls. I'm not realy > concerned with shared variables at this point, since I think there is > a chunk of work to do in just getting threads to work. > > I'm not mailing this onto the list, since I'm sure not too many people > want to get attachments. > > Shane > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
