Well, for every library you establish a separate lock. Every time you enter that library, take the lock. When you return from a call to the library, release the lock. Do this in each and every call that PHP can make to the library. The POSIX locking facilities would be adequate. This would guarantee that there would be no concurrent accesses to the library.
What we are asking for in these rewrites is for what are presently global variables to be made part of a structure that is allocated per-thread by a library call and then passed to all calls to that library as an argument. You don't have to use any magic POSIX thread-local memory stuff to do this, and it's portable. No software logic need change. If this point is made effectively to the maintainers of these libraries, they'd do it.
If the thread gets destroyed or exploited outside of PHP in one of these other libs, HOW is that PHP's fault?
Some programs do unwind context on catching a signal. Especially those that provide an exception mechanism.
Consider that this could be a speed vs. space tradeoff. They are inefficient in terms of memory use. However, it's nice to have memory that is private to a thread such that only that thread accesses the entire memory page. That means that the caches and the TLBs don't invalidate as often because some other CPU has touched the data. Remember that in a multi-processor system the cache and TLBs have to watch what is happening on the bus, and invalidate themselves when they see someone else do a write to some data that they hold. Given that we have really fast processors and slow memory, this can get expensive.
So, why don't they put a lock around the PHP interface to those libraries? Or why don't they make thread-safe successors of those Free libraries that, presumably, they do have the power to edit?
For most web servers on Linux, once the server has figured out what static file to send, it calls sendfile() and the rest of the work is entirely in the kernel until the file has been transmitted. On certain network cards, sendfile() has the property of being able to DMA from the disk to the network card without intermediate buffers. At least for big files, this is probably running very close to the hardware limit. For small files, the server efficiency is more of a factor.
It's because there are potentially random problems because of two threads writing the same data at the same time. Code that depends on the value of a global variable not changing from one line to the next might break. Imagine that you increment a variable and then assume that its value is one greater than before, but it's really two greater.
To their defense, the PHP folks say the problem is with libraries they don't control. But there could be a thread-safe PHP interface to them.
And I guess the bottom line is that they don't want to keep answering questions about this, so they just say don't upgrade to Apache 2.
Me, I use Zope. I think it's always been multithreaded.
No problem with the respect, this is an area in which I don't have tremendous expertise. But I submit that if PHP itself is in charge of its interface to a non-thread-safe library, it can put a lock around calls into it - effectively single-threading each library and that would perform at least as well as going to a less efficient threading model for apache, and potentially better depending upon where contention happens. And given that this is Free Software, thread-safe successors of those libraries can be developed.
I suspect, and here I'm out on a limb, that it's a fundamental architecture issue. PHP simply did not have global thread-safety as a design goal. And thus it could be difficult to remedy at this late date, especially if it's to be done without breaking things.
It's OK because I didn't read any of the articles linked to in the Slashdot story before posting. Thus, I maintain the proper level of ignorance for Slashdot.
On the other hand, I had looked at the problem reasonably hard when choosing supported software for UserLinux, so I did know something about the problem. So perhaps that disqualifies me.
Either PHP itself, or many PHP applications, are not written to deal with the multi-threading offered by Apache 2.0 . So, it seems, you will do best if you install one of the less optimal threading models. And then you lose much of the benefit of Apache 2.
Apache 2 and a recent Linux kernel come pretty close to the theoretical limits of the hardware when it comes to serving static content. It just loafs along while saturating whatever net connection you give it. It's worth trying out.
In order to make a legitimate complaint, I need to be in touch with one person who has the binary, and one who is a copyright holder who is being infringed.
One would think hardware manufacturers go through that same process of looking at their options every time they create a new device. Their future options will be PalmOS Cobalt self-hosting, PalmOS for Linux, Windows CE, and a host of lesser-known platforms. So, they get an additional option.
You are also assuming that PalmSource will take a long time to do this. It's not necessarily so, since they are picking up a company with an existing mobile Linux implementation, and they (finally) have their ARM port of PalmOS to put on top of it.
Computers depreciate faster than fresh fruit. I think by the time this OS version is available, it will be time to pick up some new, more powerful, hardware. With a phone and camera in it. The programs you write for your Zire will run on that platform.
Palm-sized I/O is a problem. My surmise is that voice recognition is the best solution, but requires lots of power and memory. Unless we can go to non-clocked CPUs or processing distributed in memory, we won't be able to do it on battery power. For the present, I want some sort of chord keys on the side or back of the unit. I will pay the price of learning how to key in that way. I actually considered using Morse code (which I already know) on the side buttons, but they'd probably wear out too quickly.
It's interesting that you can take so many features out of the 2.6 kernel and the remainder still runs fine. I don't think anyone has ever made a successful OS where the modularity gets so close to the core. Even on microkernel operating systems, the stuff on top of the microkernel could never be picked apart quite so well.
If I had my druthers I would have PalmSource use the Trolltech model and GPL more stuff than they have proposed to do. Remember that it took Trolltech years to be convinced to adopt that model. Give PalmSource some time, and perhaps someday it will happen.
Well, give them a chance to act. They've said they are getting into Linux now. What I mainly want from them is to have their hardware partners using Linux, so that we can hack the platforms to do what we want. It happens that my phone is a Treo 600, becuase I didn't want to drop $900 on the Motorola phone which would have been the only usable Linux phone available for U.S. GSM, and T-Mobile has been unloading the 600 for $150 to make room for the 650. With PalmSource partners running Linux, we will have the hardware we want at reasonable prices.
Well, I am not apologizing for them because they did have a big problem blocking them and they are a few years late in getting it out of the way.
Now that PalmOS 6 is coming out (the one before Linux) they will at least have a native ARM api. Up until now they have been running the OS in 68k emulation, and I am surprised it works as well as it does. It was almost impossible to write an ARM program for the device and they had to fix that first. Now they can work on such things as Java.
Note to tech managers: don't let people write more than the minimum necessary code in assembler, it will come back and hit you later.
Slashdot Mirror
Bruce
That's OK, you're only a figment of my imagination anyway :-)
Bruce
It still seems to me to be an architecture issue.
Bruce
Bruce
Bruce
Bruce
To their defense, the PHP folks say the problem is with libraries they don't control. But there could be a thread-safe PHP interface to them.
And I guess the bottom line is that they don't want to keep answering questions about this, so they just say don't upgrade to Apache 2.
Me, I use Zope. I think it's always been multithreaded.
Bruce
Bruce
Bruce
On the other hand, I had looked at the problem reasonably hard when choosing supported software for UserLinux, so I did know something about the problem. So perhaps that disqualifies me.
Bruce
Apache 2 and a recent Linux kernel come pretty close to the theoretical limits of the hardware when it comes to serving static content. It just loafs along while saturating whatever net connection you give it. It's worth trying out.
Bruce
Bruce
You are also assuming that PalmSource will take a long time to do this. It's not necessarily so, since they are picking up a company with an existing mobile Linux implementation, and they (finally) have their ARM port of PalmOS to put on top of it.
Bruce
Bruce
Thanks
Bruce
Bruce
Bruce
Bruce
Bruce
Bruce
Bruce
Bruce
Now that PalmOS 6 is coming out (the one before Linux) they will at least have a native ARM api. Up until now they have been running the OS in 68k emulation, and I am surprised it works as well as it does. It was almost impossible to write an ARM program for the device and they had to fix that first. Now they can work on such things as Java.
Note to tech managers: don't let people write more than the minimum necessary code in assembler, it will come back and hit you later.
Bruce
Bruce