 |
| Fig 1. An extremely confusing sign |
I've written on my blog, spoken in my talk, told strangers on the train: You should not use multi-threading at the front end of a web application, it does not make sense when the threading model is 1:1.
Regardless of the fact that I wrote pthreads, and I know very well what is suitable and what is not, my advice is ignored: I get endless bug reports and questions with example code containing HTML line breaks, and reports that Apache or FPM is not behaving itself.
This is no real surprise, why should anyone listen to me ...
You ruddy well will listen to me, this morning I released v3.0.6 of pthreads and it disables the ability to load pthreads anywhere but the CLI.
When I first wrote pthreads, I wanted the barrier to entry to be low. Years later, I can see clearly that was a stupid thing to aim for; The barrier to entry is not low no matter what I do.
I thought it's no big deal if someone wants to use pthreads in their webserver, pthreads uses all the right API's it should be safe, even if it's not a good idea.
I was totally wrong. It's not safe, and never will be.
When I say safe here, I don't necessarily mean safe in the re-entrant, thread safety sense. What I mean is logically sound, which includes safe in the concurrency sense of the word.
Rather than trying to focus on making pthreads accessible, I have switched my focus to making pthreads v3 robust, reliable, predictable. These are the things that are really important when you are writing multi-threaded code, ease of use or accessibility shouldn't even be on the list of things you want a multithreading API to be.
I think, I can claim a modicum of success, even though v3 is not widely used yet.
Code that didn't work before, or behaved strangely, just works now. pthreads is faster, it's simpler internally. It is more accessible and easier to use. But, not because I aimed for those things, but because I aimed for predictability.
All the while, people were still able to ignore probably the most important piece of advice I ever give.
To show that my distain for using threads in a webserver runs deep among all programmers that understand the systems they are using, and is not in any way specific to PHP, pthreads, Apache or FPM:
This response was given to a person asking if it's okay to multithread in a web response inside IIS (C#):
Many such questions can be found on stackoverflow, the best answer isn't always the accepted one. People tend to accept what they wanted to hear.
EJB's expressly prohibit the programmer from creating threads by specification, and modern Java doesn't even have a 1:1 model. Obviously, this is mostly because the environment may be migrated (moved within a cluster of servers), moving threads outside of it's managed pool is difficult to imagine. It goes further than prohibiting the creation of threads though, it prohibits the use of synchronization primitives, because what if a node is moved while you retain a lock - all hell breaks loose.
In Java generally, you are discouraged from manually creating threads in Servlets, for all the same reasons I have discouraged it for pthreads.
While it's true that not every environment will actually prohibit it, it runs as deep as can be; Everyone agrees that creating real (1:1) threads in a web response context is a bad idea.
If you're creating threads inside your multi-process, multi-threaded Apache environment, and you see this as a restriction, you're wrong, just like I was wrong to allow it.
Advice is, quite obviously, only worth something if you are going to listen to it.
Maybe I wasn't ignored, maybe pthreads has a farther reach than the advice that accompanies it, I don't know. It doesn't matter now, pthreads won't work in these environments ...
It's okay to be wrong, it's an opportunity to learn, to do things the correct way ... take the opportunity.
I'm going to go back to code now ...
