# Multi-threading - Thread: https://externals.io/message/35671 - Original archive: https://news-web.php.net/php.internals/35671 - Started by Felipe Ribeiro on 2008-02-21T03:36:02+00:00 - Messages: 11 - 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 --- ## #35671 — Felipe Ribeiro — 2008-02-21T03:36:02+00:00 URL: https://externals.io/message/35671#35671 Hello, I've been reading this list for a couple of months and I have a question that might have already been discussed here before and I haven't seen, so please apologize me. My question is if there's any intent to have multi-threading support to PHP in a future version, like PHP7. I know multi-threading is an enormous source of bugs, but I think it does offer a good support for large-scale apps considering the background processes and event-driven programming, and also allowing the apps to be self-content with no needs and no dependency of external daemons like cron. So, what's the opinion of the PHP maintainers? Regards, -- Felipe Ribeiro felipernb@gmail.com http://feliperibeiro.com 83 9979-3161 --- ## #35672 — David Coallier — 2008-02-21T03:47:37+00:00 URL: https://externals.io/message/35671#35672 · In reply to: #35671 > Hello, > > I've been reading this list for a couple of months and I have a > question that might have already been discussed here before and I > haven't seen, so please apologize me. > > My question is if there's any intent to have multi-threading support > to PHP in a future version, like PHP7. > > I know multi-threading is an enormous source of bugs, but I think it > does offer a good support for large-scale apps considering the > background processes and event-driven programming, and also allowing > the apps to be self-content with no needs and no dependency of > external daemons like cron. > I have spoken to a few people lately about this and to be honest, the opinion I get out of multi threading in php is basically "no one cares doing it, no internals need it so badly that he'll implement it, and find people to maintain it" Opening this thread is a good idea I think, after this I'll gather all ideas and comments and make a good post out of it. > So, what's the opinion of the PHP maintainers? > > Regards, > > -- > Felipe Ribeiro > felipernb@gmail.com > http://feliperibeiro.com > 83 9979-3161 > > -- > > > > -- David, Re-read what you are replying. --- ## #35673 — Tim Starling — 2008-02-21T04:47:35+00:00 URL: https://externals.io/message/35671#35673 · In reply to: #35671 Felipe Ribeiro wrote: > Hello, > > I've been reading this list for a couple of months and I have a > question that might have already been discussed here before and I > haven't seen, so please apologize me. > > My question is if there's any intent to have multi-threading support > to PHP in a future version, like PHP7. > > I know multi-threading is an enormous source of bugs, but I think it > does offer a good support for large-scale apps considering the > background processes and event-driven programming, and also allowing > the apps to be self-content with no needs and no dependency of > external daemons like cron. > > So, what's the opinion of the PHP maintainers? > Just an uninformed thought: maybe the existing TSRM framework could be leveraged to provide some simple multithreading support to the user. User threads could get their own set of engine globals, initialised in the same way that multithreaded SAPIs do it. Inter-thread communication would be handled by a small set of thread-safe transfer functions, which would copy data between distinct memory pools. Threads could be started by specifying a string or file to compile and execute in the new environment. It'd be heavyweight compared to an ordinary threaded application, but lightweight compared to multiprocessing by shelling out to subsidiary scripts via the CLI SAPI. Then incremental development could head in the direction of more efficient data transfer, oparray sharing, and support for threaded concepts like locks and worker pools. -- Tim Starling --- ## #35680 — Alexey Zakhlestin — 2008-02-21T08:52:03+00:00 URL: https://externals.io/message/35671#35680 · In reply to: #35671 well, there is http://pecl.php.net/package/threads it was never finished, thogh Here's the thread about it, from last august: http://thread.gmane.org/gmane.comp.php.pecl.devel/3996 > Hello, > > I've been reading this list for a couple of months and I have a > question that might have already been discussed here before and I > haven't seen, so please apologize me. > > My question is if there's any intent to have multi-threading support > to PHP in a future version, like PHP7. > > I know multi-threading is an enormous source of bugs, but I think it > does offer a good support for large-scale apps considering the > background processes and event-driven programming, and also allowing > the apps to be self-content with no needs and no dependency of > external daemons like cron. > > So, what's the opinion of the PHP maintainers? > > Regards, > > -- > Felipe Ribeiro > felipernb@gmail.com > http://feliperibeiro.com > 83 9979-3161 > > > -- > > > > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #35682 — Nathan Rixham — 2008-02-21T11:33:10+00:00 URL: https://externals.io/message/35671#35682 · In reply to: #35672 David Coallier wrote: > > > […] > > I have spoken to a few people lately about this and to be honest, the > opinion I get out of multi threading in php is basically "no one cares > doing it, no internals need it so badly that he'll implement it, and > find people to maintain it" > > Opening this thread is a good idea I think, after this I'll gather all > ideas and comments and make a good post out of it. > > > […] > > > David, hope you don't mind me asking for a bit more info, I was always under the impressions that a thread is defined as (quote wiki) "Threads are a way for a program to fork (or split) itself into two or more simultaneously (or pseudo-simultaneously) running tasks. Threads and processes differ from one operating system to another but, in general, a thread is contained inside a process and different threads of the same process share some resources while different processes do not." and php supports pcntl_fork along with signal handlers and interprocess communication via functions like or stream_socket_pair. as such if I set up a cli app with parent and child processes (?threads), then isn't this multithreading in php? I know this strictly isn't the place for such questions, but I hope you won't mind enlightening me a little on the matter. Many Regards in advance, Nathan --- ## #35683 — Alexey Zakhlestin — 2008-02-21T11:53:39+00:00 URL: https://externals.io/message/35671#35683 · In reply to: #35682 > hope you don't mind me asking for a bit more info, I was always under > the impressions that a thread is defined as (quote wiki) > > "Threads are a way for a program to fork (or split) itself into two or > more simultaneously (or pseudo-simultaneously) running tasks. Threads > and processes differ from one operating system to another but, in > general, a thread is contained inside a process and different threads of > the same process share some resources while different processes do not." > > and php supports pcntl_fork along with signal handlers and interprocess > communication via functions like or stream_socket_pair. > > as such if I set up a cli app with parent and child processes > (?threads), then isn't this multithreading in php? > > I know this strictly isn't the place for such questions, but I hope you > won't mind enlightening me a little on the matter. it is not multithreading. multithreading means that a process starts several "threads" which work simulatenously and share local resources (such as variables, dynamically created functions/classes, database connections, etc.) pcntl_fork creates several processes, which can communicate, but still has their own sets of local resources -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #35686 — Nathan Rixham — 2008-02-21T12:29:40+00:00 URL: https://externals.io/message/35671#35686 · In reply to: #35683 Alexey Zakhlestin wrote: > > > […] > > it is not multithreading. > multithreading means that a process starts several "threads" which > work simulatenously and share local resources (such as variables, > dynamically created functions/classes, database connections, etc.) > > pcntl_fork creates several processes, which can communicate, but still > has their own sets of local resources > Thankyou for taking the time to shed some light on the mater for me; I'd missed the all vital "sharing resources" part of the concept, probably because (if I'm correct in saying) php shares memory of variables/classes/resources between parent and child processes until a write occurs, at which point a new version of the aforementioned is created. [please correct if wrong]. Would I therefore be correct in assuming the following: In PHP we can create mutli-process(tasking) applications that have most of the benefits of multi-threaded applications and less bugs. I'm working on the premise that a processor can only run so fast, so multithreading say 100k calculations would not speed up and application, if anything it would add overhead, and slow it down. The only way to speed up such an application would be to throw more hardware at the problem (be it servers or processors). Meaning that the only time multi-process/multi-threading would have any positive bearing on an application would be when dealing with things such as external resources, due to the slower access times of these external resources we find threads/processes "waiting" for the resource to be usable (fully downloaded/opened) - in such a situation multi-threading has it's distinct advantages. However forking an app (?multi-process) can already achieve the same results, the only difference being that we may have a few duplicate classes/variables around the application doing it this way (subject to us not taking the time to define all "shared" resources in the parent process. If I'm correct in all of the above, then I'd personally think that we don't need multithreading in PHP, however a neat(er) predefined method of interprocess communication would be beneficial. Thoughts/Corrections? Regards Nathan --- ## #35692 — Alexey Zakhlestin — 2008-02-21T14:47:02+00:00 URL: https://externals.io/message/35671#35692 · In reply to: #35686 > Thankyou for taking the time to shed some light on the mater for me; I'd > missed the all vital "sharing resources" part of the concept, probably > because (if I'm correct in saying) php shares memory of > variables/classes/resources between parent and child processes until a > write occurs, at which point a new version of the aforementioned is > created. [please correct if wrong]. `pcntl_fork()` uses fork() call which is implemented in OS. Forked process is a copy of parent process, which means, that it occupies similiar amount of memory. Each time you "fork" your memory usage gets bigger > Would I therefore be correct in assuming the following: > > In PHP we can create mutli-process(tasking) applications that have most > of the benefits of multi-threaded applications and less bugs. > > I'm working on the premise that a processor can only run so fast, so > multithreading say 100k calculations would not speed up and application, > if anything it would add overhead, and slow it down. The only way to > speed up such an application would be to throw more hardware at the > problem (be it servers or processors). If your task is CPU-bound, you can't do much, but give it more hadrware. (we are not talking about optimization of algorithms here) > Meaning that the only time multi-process/multi-threading would have any > positive bearing on an application would be when dealing with things > such as external resources, due to the slower access times of these > external resources we find threads/processes "waiting" for the resource > to be usable (fully downloaded/opened) - in such a situation > multi-threading has it's distinct advantages. > > However forking an app (?multi-process) can already achieve the same > results, the only difference being that we may have a few duplicate > classes/variables around the application doing it this way (subject to > us not taking the time to define all "shared" resources in the parent > process. Multithreading can be dramatially good for memory-bound tasks. It is possible to say (although, this is oversimplification), that threads are "light processes". They allow to execute a lot of parallel tasks with less overhead > If I'm correct in all of the above, then I'd personally think that we > don't need multithreading in PHP, however a neat(er) predefined method > of interprocess communication would be beneficial. -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ --- ## #35695 — Stanislav Malyshev — 2008-02-21T17:34:33+00:00 URL: https://externals.io/message/35671#35695 · In reply to: #35673 Hi! > Just an uninformed thought: maybe the existing TSRM framework could be > leveraged to provide some simple multithreading support to the user. TSRM is meant to support "share nothing" in threaded environment. Multi-threading should support sharing data (including locking & synchronization) which is quite different business. It may be easier to do pseudo-multithreading a-la Python, where there's only one thread running at each moment of time, but they can switch when other threads are waiting for something like I/O or some event. That would require some work for defining engine state and enabling switching, but it's easier than full multithreading support. Unfortunately, as for now nobody showed real interest in doing that. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #35696 — Stanislav Malyshev — 2008-02-21T17:40:34+00:00 URL: https://externals.io/message/35671#35696 · In reply to: #35671 Hi! > I know multi-threading is an enormous source of bugs, but I think it > does offer a good support for large-scale apps considering the > background processes and event-driven programming, and also allowing Multithreading does not fit well in the set of assumptions PHP engine is built on (though as for PHP language itself, I don't think there are assumptions that contradict threads) so it would be quite hard to do it on existing engine. It might be easier to do on some non-standard implementations, but I wouldn't hold my breast about standard engine - unless somebody comes forward and surprises us. > the apps to be self-content with no needs and no dependency of > external daemons like cron. I'm not sure how cron enters here but if what you need is scheduling capabilities then there are products implementing this, e.g. in Zend Platform. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com --- ## #35722 — Tim Starling — 2008-02-22T08:54:33+00:00 URL: https://externals.io/message/35671#35722 · In reply to: #35695 Stanislav Malyshev wrote: > Hi! > > > […] > > TSRM is meant to support "share nothing" in threaded environment. > Multi-threading should support sharing data (including locking & > synchronization) which is quite different business. > > It may be easier to do pseudo-multithreading a-la Python, where > there's only one thread running at each moment of time, but they can > switch when other threads are waiting for something like I/O or some > event. That would require some work for defining engine state and > enabling switching, but it's easier than full multithreading support. > Unfortunately, as for now nobody showed real interest in doing that. I'm saying that you could make multiple "share nothing" instances available to the user, for a programming model intermediate between multiprocessing and traditional threading. Python-style multithreading wouldn't be useful for the applications I have in mind. -- Tim Starling