On 01.04.2010, at 22:38, Stanislav Malyshev wrote: > Hi! > >> processing, but then the state syncing of the forked background >> processing >> results with the main thread requires a whole new protocol / switching >> to >> interprocess communication, which makes such developments unnecessarily >> hard. Threads exist for a _reason_ not only because they sound cool. > > Interesting thing here threads would require (at least if they are > implemented the way C, etc. threads usually work) whole new protocol of > synchronization too. Just think about something: do you have shared > classes/variables/etc.? > If you do, how you control access to them? Hello locks and the whole can of > worms! Most people that think they can program in threads actually are just > pushing their luck until some complex interaction leaves their app > malfunctioning in a bizarre way and them without any means to debug it. I > mean, you can do it right, but it's usually harder than it looks. > Share-nothing exists for a reason too :)
Well, strictly speaking, there are [at least] 2 models which can be used: 1) Classical with shared resources and locking 2) STM Anyway, do we really have to tell people "you don't need it" when they believe that they do? Python has multithreading and it works reasonably good. People who know what they are doing can implement really brilliant solutions (think Tornado) And something like GIL feels like a reasonable compromise to me. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
