After some effort, I managed to set up a PHP multithreaded server that receives input from multiple WebSockets and passes it on to a single TCP socket. I accomplished this with pthreads and managed to use the Stackable object as an array.
The next step now is to really understand what I'm doing and most definitely what I can do better. I read somewhere here on SO that multithreading is not something you just 'do'. For that reason I like to dig deeper first before I move on coding. Brings me to these questions:
What is meant by A Worker Thread has a persistent state
(pthreads.org). Will a Worker continue running when out of scope? What is their relation to Stackables?
The PHP manual says Worker threads should be used over Threads, why?
I hope my question is not to broad.
A Worker Thread has a persistent state: when you start a worker thread, the worker is available for execution until the variable goes out of scope or the worker is shutdown.
Take the example of a script that downloads multiple pages from multiple sources online: on a tiny scale, you might get away with, and it might be the best design to have multiple threads, each thread dealing with a single request and processing the content. However, normally, you should consider it a huge waste to start a thread to make a single request, or execute anything very simple, instead you would start as many workers as your hardware and environment can manage, and implement the request and processing of content as a Stackable. When using Workers, each request does not cost you the initialization of a threading context. Persistence in this context refers to the fact that each of the Stackables can read $this->worker, and access all/any of the global (including class level static variable) scopes, so from the perspective of the Stackable during execution the context of the Worker persists, in reality the Stackables are simply sharing a context.
Mutex and Cond are there for hardcore posix threading addicts, and for my purposes during development of pthreads itself. Normal users shouldn't really have to use this functionality, though it's as well documented as the counterpart posix functions, and much of the original documentation still applies (with a layer of sensible on top). Mutex and Cond are both thin wrappers around familiar functionality, and not really aimed at Joe Bloggs.
I guess you are wondering if mutex are required in order to have safe reading and writing of objects, this is not the case, safety is built into pthreads.
Times you should use a Thread over a Worker would be; from the example, on the tiny scale. Additionally, if you have the hardware to support it, Threads can create Workers (and Threads), which lends itself to more complex systems design possibilities. You might also turn out to be awesome at this, in which case you can program your threads to act like workers without the overhead of object initialization (stackables) for every task. A Worker is a Thread, only some of the Thread's functionality has been hi-jacked to execute a list of Stackables, you will notice subtle differences in the synchronization methods of Thread and Worker, which doesn't matter if you are using workers as intended. If however your awesomeness leads you to think it'd be better to avoid the standard model, then you will require the synchronization from a Thread object to implement a Worker pattern in PHP.
The fact is, that if you are looking at threading, you are wanting to do more than 2 or 3 things at a time, the chances are that you could have found ways to do a few things. So providing Worker/Stackable functionality as part of the pthreads package makes sense, because it's better suited to executing a bunch of things in separate contexts, writing this stuff in PHP (even with the help of pthreads) would be tricky.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With