You do not understand the issue. Just removing the interpreter lock would make Pike crash almost immediately when you start a second thread. You need to replace the interpreter lock with more fine-grained locks that lock only the data that each thread is currently working on. Those extra lock/unlock operations is what slows down Pike.
The only other option is to use some sort of data isolation, so that a thread doesn't have to lock it's data, because no other thread can access it.
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2004-02-01 15:48: Subject: Re: Default backend and thread backends?
If you're referring to the interpreter lock which protects against thread switching under particular conditions I don't know if that's considered part of the language specs (are the conditions documented at all?). Still, a quick grep in the Roxen source code found less than three dozen commented occurrences out of ~250KLOC so it's hopefully not too difficult to mark those parts with #pragma directives or something similar. A nice start would be to devise a method today so that code written from now on is safe.
Anyway, I'm just hoping that multiprocessing wasn't discarded years ago never to be reconsidered again, even if it means we'll have to sacrifice some nice properties of the current implementation (like O(1) string comparisons due to a global string table etc).
/ Jonas Walldén