Re: php and multithreading (additional arguments)
| From: | Alexey Zakhlestin | Date: | Thu, 01 Apr 2010 20:15:50 +0000 |
| Subject: | Re: php and multithreading (additional arguments) | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-47721@lists.php.net to get a copy of this message | ||
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.