# php and multithreading (additional arguments) - Thread: https://externals.io/message/47701 - Original archive: https://news-web.php.net/php.internals/47701 - Started by speedy on 2010-04-01T14:32:15+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/47701.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #47701 — speedy — 2010-04-01T14:32:15+00:00 URL: https://externals.io/message/47701#47701 Hello PHP folks, I've seen this discussed previously, and would like to add a few arguments for the multi-threading side vs. async processing, which I've seen mentioned as a viable alternative: 1. Imagine that from time to time, some background processing takes 1 second of CPU time - w/o multithreading, all your async operations, like accepting a connection to a socket, aio or others are basically stalled. So, async is a good approach, but does not work as a magic wand for all problem spaces. Alternatively, you could fork and then do the 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. 2. Without thread support, it is not possible to use multi-core processing paradigms directly from PHP - which means PHP relies on external frameworks for that feature, which, in a sense, makes it a non-general-purpose language. It _could become_ a general purpouse tool, if it had proper multi-threading support built-in. I, personally, considered developing websockets / nanoserv server stack with PHP and bumped into the multithreading limitation - AFAIK it is the only big feature separating PHP from the general purpouse languages. Everything else is well integrated with lots of external libraries/modules giving rise to potential rapid application development while using it. Cheers and let me know about your thoughts, and potential core implementation issues regarding developing this language feature. -- Best regards, speedy mailto:speedy.spam@gmail.com --- ## #47702 — Rasmus Lerdorf — 2010-04-01T15:21:55+00:00 URL: https://externals.io/message/47701#47702 · In reply to: #47701 > 1. Imagine that from time to time, some background processing takes 1 > second of CPU time - w/o multithreading, all your async operations, > like accepting a connection to a socket, aio or others are basically > stalled. So, async is a good approach, but does not work as a magic > wand for all problem spaces. Alternatively, you could fork and then do the > 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. There are plenty of mechanisms/protocols for doing this. Gearman works extremely well for managing out-of-band jobs like this, for example. > 2. Without thread support, it is not possible to use multi-core processing > paradigms directly from PHP - which means PHP relies on external frameworks for > that feature, which, in a sense, makes it a non-general-purpose language. > It _could become_ a general purpouse tool, if it had proper multi-threading > support built-in. PHP is not a general-purpose language and there are no plans to make it one. Your OS provides scheduling and is responsible for making best use of your multiple cores. With many concurrent web requests your multiple cores should be put to good use. -Rasmus --- ## #47703 — speedy — 2010-04-01T16:03:11+00:00 URL: https://externals.io/message/47701#47703 · In reply to: #47702 Hello Rasmus, Thursday, April 1, 2010, 5:21:55 PM, you wrote: > > > […] > There are plenty of mechanisms/protocols for doing this. Gearman works > extremely well for managing out-of-band jobs like this, for example. Yes, but sometimes, esp. in more real-time oriented applications, state merging is very hard to do - though I agree that protocols and mechanisms exist for out of band processing, there are plenty of cases in which they are suboptimal. > > […] > PHP is not a general-purpose language and there are no plans to make it > one. Your OS provides scheduling and is responsible for making best use > of your multiple cores. With many concurrent web requests your multiple > cores should be put to good use. Current situational facts are against that claim - with PHP delivered as a CLI interpreter, and via that route, having more and more software applications written outside the web serving scope/domain, PHP has spontaneously made strides into becoming a general purpouse tool. I think the only remaining step in that direction is to have the native multi-threading support. I plan to check out how hard would that be, and see how many people would be needed for developing that feature in some reasonable time-frame. Also, keep in mind that the web is slowly shifting towards real-time communication / streaming with emergence of Comet, HTML5 Web Sockets etc. There are already many web server implementations specialising in that, and PHP is _not_ their language of choice. > -Rasmus -- Best regards, speedy mailto:speedy.spam@gmail.com --- ## #47704 — Rasmus Lerdorf — 2010-04-01T16:16:21+00:00 URL: https://externals.io/message/47701#47704 · In reply to: #47703 > Also, keep in mind that the web is slowly shifting towards real-time communication > / streaming with emergence of Comet, HTML5 Web Sockets etc. There are already many web > server implementations specialising in that, and PHP is _not_ their language of choice. The large comet implementations I know about use a high performance proxy to hold hundreds of thousands of open sockets and then they have a dispatching mechanism to route individual requests to the various backend processing engines. PHP is very much part of that picture, and again, given that the concurrency is invariably going to be high, multi-core usage is handled by your OS. In any sort of Web architecture native threading in PHP just doesn't make any sense. In single monolithic CLI apps, you could make a case for it, but that is not the sort of architecture we are going to put a significant amount of time into. -Rasmus --- ## #47705 — speedy — 2010-04-01T17:27:06+00:00 URL: https://externals.io/message/47701#47705 · In reply to: #47704 Hello Rasmus, Thursday, April 1, 2010, 6:16:21 PM, you wrote: > In any sort of Web architecture native threading in PHP just doesn't > make any sense. Imagine a real-time websockets/HTTP based server processing architecture with quick event passing from one connection to another with possibility of each web client broadcasting events to all other web clients. A simple example: web chat, and a complex one: real-time web MMO game. Now imagine a whole web server written in PHP (ie. nanoserv), say, using libevent as the network backend, running the above described real-time web implementation. Alternatively, you could perhaps even wire it into worker/event model of apache/other servers instead of rolling your own. It sounds quite powerful, and development-effort-wise cheap - out of a mere HTML preprocessor! With proper threading, this would be a piece of cake to implement in PHP, efficiently and ensuring low latency, using up all available CPU cores / resources. Without using native threads, the whole class of web architectures on both server and processing levels, viewed both separately or together, are quite a bit more hairy to implement. > In single monolithic CLI apps, you could make a case > for it, but that is not the sort of architecture we are going to put a > significant amount of time into. Yep, agreed and understood. > -Rasmus -- Best regards, speedy mailto:speedy.spam@gmail.com --- ## #47706 — Jonah H. Harris — 2010-04-01T17:59:10+00:00 URL: https://externals.io/message/47701#47706 · In reply to: #47705 > Now imagine a whole web server written in PHP (ie. nanoserv), say, using > libevent as the network backend, running the above described real-time web > implementation. Alternatively, you could perhaps even wire it into > worker/event > model of apache/other servers instead of rolling your own. It sounds quite > powerful, > and development-effort-wise cheap - out of a mere HTML preprocessor! > > With proper threading, this would be a piece of cake to implement in PHP, > efficiently > and ensuring low latency, using up all available CPU cores / resources. > > Without using native threads, the whole class of web architectures on both > server > and processing levels, viewed both separately or together, are quite a bit > more hairy > to implement. > Sorry, but as a performance-oriented C developer who has written a good amount of stuff directly against libevent, I'm having a hard time not laughing at this thread. Why would anyone want to write such a thing directly in PHP, or any other scripting language for that matter? If you're worried about performance, you're going to have to do it in something either low-level or that is natively compiled. In the scripting language world, I can only think of something like Lua with libevent bindings as being capable of performing fairly well in a multi-threaded environment (given no GIL). Though, even in that case, you'd still have a good amount of custom work to do. I've worked with libevent-based Comet servers written in C, and there's *no way* a scripting language version is going to handle memory management, messaging, and queueing for a large number of connections effectively. Similarly, you'll never really be able to approach near-real-time processing in this type of environment given basic abstraction/interpretation/scheduling issues. These are very basic systems architecture issues and it's obvious that scripting languages are *not* designed for what you're asking. Not to sound demeaning, but do you have any real need for what you're asking, or are you just saying, "gee, it would be nice for me to be able to write a Comet server in 99 lines of PHP that is capable of managing 60K concurrent connections and a rate of 15K messages/second with a maximum latency of 50ms?" Sorry, I'm a little grumpy today... -- Jonah H. Harris Blog: http://www.oracle-internals.com/ --- ## #47707 — Brian Moon — 2010-04-01T18:02:17+00:00 URL: https://externals.io/message/47701#47707 · In reply to: #47705 > Now imagine a whole web server written in PHP (ie. nanoserv), say, using > libevent as the network backend, running the above described real-time web > implementation. Alternatively, you could perhaps even wire it into worker/event > model of apache/other servers instead of rolling your own. It sounds quite powerful, > and development-effort-wise cheap - out of a mere HTML preprocessor! PHP works fine in Apahce worker now if you know what you are doing and don't do stupid things with PHP in a web environment. Keep all the stupid stuff in Gearman, cron or non-threaded servers. This is just not what PHP is for. Brian. --- ## #47708 — Stanislav Malyshev — 2010-04-01T18:38:02+00:00 URL: https://externals.io/message/47701#47708 · In reply to: #47701 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 :) If you don't, how it's different from forking except that you need to work 10 times as hard to keep engine guts from entangling in two "threads"? > 2. Without thread support, it is not possible to use multi-core processing > paradigms directly from PHP - which means PHP relies on external frameworks for What kinds of paradigms those are? in 90% of cases I saw if you need real multicore involvement in PHP you either doing it in a wrong place (i.e. webserver vs. backend) or doing it in a wrong language. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #47709 — Antony Dovgal — 2010-04-01T18:52:13+00:00 URL: https://externals.io/message/47701#47709 · In reply to: #47708 > 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. Well, I don't agree with the statement above, but I do believe that if you're competent enough to use threads, then you're competent enough to write in C/C++. Not to mention that a high-performance multi-threaded daemon written in PHP is a total nonsense - that's exactly the task C/C++ do much better/faster. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #47710 — Pierre Joye — 2010-04-01T18:54:56+00:00 URL: https://externals.io/message/47701#47710 · In reply to: #47709 are we talking about having a thread safe PHP or parallel-like features available in user land? The sooner needs some love to be actually true, while most of the issues come from external libs. The later makes little or no sense. > > > […] > > Well, I don't agree with the statement above, but I do believe that if you're competent > enough to use threads, then you're competent enough to write in C/C++. > > Not to mention that a high-performance multi-threaded daemon written in PHP > is a total nonsense - that's exactly the task C/C++ do much better/faster. > > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP > > -- > > > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47712 — Antony Dovgal — 2010-04-01T19:02:34+00:00 URL: https://externals.io/message/47701#47712 · In reply to: #47710 > are we talking about having a thread safe PHP or parallel-like > features available in user land? > > The sooner needs some love to be actually true, while most of the > issues come from external libs. The later makes little or no sense. We're talking about threads in userspace, of course. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP --- ## #47720 — Lester Caine — 2010-04-01T20:07:40+00:00 URL: https://externals.io/message/47701#47720 · In reply to: #47710 Pierre Joye wrote: > are we talking about having a thread safe PHP or parallel-like > features available in user land? > > The sooner needs some love to be actually true, while most of the > issues come from external libs. The later makes little or no sense. Something we agree on Pierre. The first piece of the jigsaw IS to make everything thread safe. And perhaps link to internally threaded functions such as asynchronous queries. Then a discussion about user land multi-threading may make more sense, but I think Rasmus has stated the case quite succinctly as to why that does not make sense ;) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #47721 — Alexey Zakhlestin — 2010-04-01T20:15:50+00:00 URL: https://externals.io/message/47701#47721 · In reply to: #47708 > Hi! > > > […] > > 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. --- ## #47722 — Ferenc Kovacs — 2010-04-01T20:30:51+00:00 URL: https://externals.io/message/47701#47722 · In reply to: #47721 > 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) > > 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.? Eve Online in Stackless Python fmspy.org with stackless python etc. > And something like GIL feels like a reasonable compromise to me. > I think PHP is the last from the major scripting languages on the market without some kind of thread support. (Cannot find a good comparsion, but Ruby, Python, Perl does some) Tyrael --- ## #47723 — speedy — 2010-04-01T20:43:35+00:00 URL: https://externals.io/message/47701#47723 · In reply to: #47709 Hello Antony, Thursday, April 1, 2010, 8:52:13 PM, you wrote: > Not to mention that a high-performance multi-threaded daemon written in PHP > is a total nonsense - that's exactly the task C/C++ do much better/faster. I'd like to have easily written, decently performing multi-threaded daemon. And the things in between here and there are quite hard to do, but still doable: * native multithreading (my uneducated guess: copy on write / rw-sems on the internals and mutex objects on the language level) * PHP JIT (via LLVM or similar) I do agree with the parent poster that it is a can of worms which can easily shoot you in the foot ;) Some kind of php.ini or #pragma-alike threading directive for the programmer to "unlock" it him/herself would be really smart to be had. > -- > Wbr, > Antony Dovgal > --- > http://pinba.org - realtime statistics for PHP -- Best regards, speedy mailto:speedy.spam@gmail.com --- ## #47724 — Stanislav Malyshev — 2010-04-01T21:33:59+00:00 URL: https://externals.io/message/47701#47724 · In reply to: #47722 Hi! > Eve Online in Stackless Python > fmspy.org with stackless python > etc. I don't know how python does it but PHP has a lot of global context, and sharing this global context between threads, whatever they are (OS threads, user-space threads, etc.) would be massively complex thing tp manage either for the engine or for the user. > And something like GIL feels like a reasonable compromise to me. GIL would mean dreams about multicore stuff are just dreams, but beyond that even with GIL, what do you do if you checked for class_exists and it didn't exist, and you're about to load it when other thread loads it before? Etc., etc. You'd have to spend a lot of time thinking about stuff like that in your code. The fact that GIL protects you from C-level context changes doesn't mean it'd protect you from PHP-level context changes, like some code using some data structure and other code changing it (on C level it'd be ok - no memory corruption, etc. - but on PHP level it might totally break your code). It's not to say it can't be done, but I didn't see yet coherent proposal for any threads implementation that had also good use cases. > I think PHP is the last from the major scripting languages on the market > without some kind of thread support. > (Cannot find a good comparsion, but Ruby, Python, Perl does some) And "keeping up with Joneses" is not a good use case. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #47725 — Pierre Joye — 2010-04-01T21:35:49+00:00 URL: https://externals.io/message/47701#47725 · In reply to: #47724 > Hi! > > > […] > > I don't know how python does it but PHP has a lot of global context, and > sharing this global context between threads, whatever they are (OS threads, > user-space threads, etc.) would be massively complex thing tp manage either > for the engine or for the user. Let make it slightly more clear: To do what python or perl does using the ZendEngine2 would mean a complete rewrite of the engine. It is a short answer but reflects the fact, sadly. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47728 — Dennis Hotson — 2010-04-01T23:04:52+00:00 URL: https://externals.io/message/47701#47728 · In reply to: #47701 I use `pcntl_fork()` for writing parallel multi-process applications and it works pretty well. Also, you can use shared memory queues to pass messages between processes (ie msg_get_queue()). I wrote a little proof of concept library a while ago to demonstrate: http://github.com/dhotson/Phork It's not that complicated... the main part of it is only ~110 lines of code: http://github.com/dhotson/Phork/blob/master/classes/Phork/Process.php Regards, Dennis > Hello PHP folks, > > I've seen this discussed previously, and would like to add a few > arguments for the multi-threading side vs. async processing, > which I've seen mentioned as a viable alternative: > > 1. Imagine that from time to time, some background processing takes 1 > second of CPU time - w/o multithreading, all your async operations, > like accepting a connection to a socket, aio or others are basically > stalled. So, async is a good approach, but does not work as a magic > wand for all problem spaces. Alternatively, you could fork and then do > the > 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. > > 2. Without thread support, it is not possible to use multi-core > processing > paradigms directly from PHP - which means PHP relies on external > frameworks for > that feature, which, in a sense, makes it a non-general-purpose > language. > It _could become_ a general purpouse tool, if it had proper > multi-threading > support built-in. > > I, personally, considered developing websockets / nanoserv server > stack with PHP > and bumped into the multithreading limitation - AFAIK it is the only > big feature > separating PHP from the general purpouse languages. Everything else is > well > integrated with lots of external libraries/modules giving rise to > potential rapid > application development while using it. > > Cheers and let me know about your thoughts, and potential core > implementation > issues regarding developing this language feature. > > -- > Best regards, > speedy mailto:speedy.spam@gmail.com --- ## #47729 — Andi Gutmans — 2010-04-02T05:16:41+00:00 URL: https://externals.io/message/47701#47729 · In reply to: #47728 Hi, I think that if we were ever to implement threading we would be best off to enable spawning worker threads that have their own context with no shared data (and therefore no requirement for locking). We could then have a message passing API between the threads. Advantages: - Real multi-threading. - Simple straightforward approach which doesn't require a comp. sci. degree to use correctly. - Very stable implementation. You can tell by this that: a) I think GIL is not the way to go. It's more complex, not truly multi-threaded, and implementation may never be 100%. b) True multi-threading with data sharing in my opinion is a recipe for disaster. Not only because of the implementation complexities but I think it makes life very hard for the developer and requires a lot of sophistication. So if I'd implement something I'd definitely do true multi-threading with message passing (we basically already have the infrastructure with TSRM to support that). Do I think this is a high priority item? Not really but I can understand that it could add value to some. I think for some Web requests it could actually allow for some parallel processing with a rendezvous which could help reduce latency (not overall server throughput). Then again, there'd be some overhead for having a thread-safe build so I don't see this as something that would be enabled by the masses - at least not initially. Andi --- ## #47731 — Jille Timmermans — 2010-04-02T07:06:25+00:00 URL: https://externals.io/message/47701#47731 · In reply to: #47729 Op 2-4-2010 7:16, Andi Gutmans schreef > I think that if we were ever to implement threading we would be best off > to enable spawning worker threads that have their own context with no > shared data (and therefore no requirement for locking). We could then > have a message passing API between the threads. > Advantages: > - Real multi-threading. > - Simple straightforward approach which doesn't require a comp. sci. > degree to use correctly. > - Very stable implementation. > That sounds like "I want threading; because it sounds cool!". What are the advantages of this above multi-process? The systemcall-overhead for message passing? And why did nobody mention Aprils Fools yesterday; when the request-for-threading was sent ;) -- Jille --- ## #47732 — Ferenc Kovacs — 2010-04-02T07:15:10+00:00 URL: https://externals.io/message/47701#47732 · In reply to: #47728 On Fri, Apr 2, 2010 at 1:04 AM, Dennis Hotson wrote: > I use `pcntl_fork()` for writing parallel multi-process applications and it > works pretty well. > Also, you can use shared memory queues to pass messages between processes > (ie msg_get_queue()). > > I wrote a little proof of concept library a while ago to demonstrate: > http://github.com/dhotson/Phork > > It's not that complicated... the main part of it is only ~110 lines of > code: > http://github.com/dhotson/Phork/blob/master/classes/Phork/Process.php > > Regards, > Dennis > > Yes, the pcntl_fork does exists, but there are some things that better with threading: * support on windows * easier inter-process/inter-thread communication/data passing. * threads are cheaper Tyrael --- ## #47733 — Ferenc Kovacs — 2010-04-02T07:20:03+00:00 URL: https://externals.io/message/47701#47733 · In reply to: #47725 > > > […] > threads, > > […] > either > > […] > > Let make it slightly more clear: To do what python or perl does using > the ZendEngine2 would mean a complete rewrite of the engine. It is a > short answer but reflects the fact, sadly. > Thats a sad thing. :( Any volunteers to do that? ;) Thank you for pointing that out. Tyrael > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #47734 — Lester Caine — 2010-04-02T07:30:49+00:00 URL: https://externals.io/message/47701#47734 · In reply to: #47731 Jille Timmermans wrote: > Op 2-4-2010 7:16, Andi Gutmans schreef > > […] > That sounds like "I want threading; because it sounds cool!". What are > the advantages of this above multi-process? > The systemcall-overhead for message passing? Actually Andi's outline forms a nice simple base for something practical. It simply builds on the 'background' threading required to run asynchronous operations while not creating a unmanageable mess. But I still can't see any need to go beyond perhaps asynchronous SQL queries. It still requires that all the non-thread safe code is addressed first? Even if that simply means disabling extensions that are not safe? > And why did nobody mention Aprils Fools yesterday; when the > request-for-threading was sent ;) Because it was after noon when it was sent ;) -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #47735 — Ferenc Kovacs — 2010-04-02T07:34:46+00:00 URL: https://externals.io/message/47701#47735 · In reply to: #47731 > Op 2-4-2010 7:16, Andi Gutmans schreef > > I think that if we were ever to implement threading we would be best off > > […] > That sounds like "I want threading; because it sounds cool!". Threading is cool. :) It has more value for me, that traits/grafts but I won't deny, that others may find it usefull, why are you? > What are the advantages of this above multi-process? > The systemcall-overhead for message passing? > I mentioned a few advantage in one of my previous post, Tyrael --- ## #47736 — Ferenc Kovacs — 2010-04-02T07:40:16+00:00 URL: https://externals.io/message/47701#47736 · In reply to: #47734 > Jille Timmermans wrote: > > > […] > > Actually Andi's outline forms a nice simple base for something practical. > It simply builds on the 'background' threading required to run asynchronous > operations while not creating a unmanageable mess. But I still can't see any > need to go beyond perhaps asynchronous SQL queries. > > Or asynchronous exec, or asynchronous(or at least timout aware) gethostbyaddr, see: http://bugs.php.net/bug.php?id=51306 So any task, that require waiting on external resource could be executed in paralel. http://hu2.php.net/manual/en/mysqli.reap-async-query.php its a good thing, that you can async mysql execution with mysqlnd. Tyrael > It still requires that all the non-thread safe code is addressed first? > Even if that simply means disabling extensions that are not safe? > > > And why did nobody mention Aprils Fools yesterday; when the > > […] > Because it was after noon when it was sent ;) > > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php --- Next page: https://externals.io/message/47701.md?page=2