I've tried doing that. But it turns out that Pike would become less than half as fast in the process, so the effort was pretty much self- defeating.
Why not just create separate interpreter object (state) for every thread, and leave thread management (mutexes, IPCs, etc) to an app?
That is an option, but you would have all the same issues when sharing data as you would when running each interpreter in a separate process as.
Another alternative would be object locks, function locks, etc (an attribute like "locked"?).
I don't think you understand the issue. Pike has a multitude of internal data structures which have to be protected. This means that hundreds or thousands of locks has to be created and locked while Pike is executing.
If I've SMP machine (and this becomes common nowadays, at least for servers), it makes sense.
But I guess it would require very extensive rewriting of interpreter, or?
Yes. (Btw, python threads have exactly the same limitations...)
/Hubbe
/ Fredrik (Naranek) Hubinette (Real Build Master)
Previous text:
2004-02-01 13:12: Subject: Re: Default backend and thread backends?
On Sun, Feb 01, 2004 at 11:25:01AM +0100, Fredrik (Naranek) Hubinette (Real Build Master) @ Pike (-) developers forum wrote:
I've tried doing that. But it turns out that Pike would become less than half as fast in the process, so the effort was pretty much self- defeating.
Why not just create separate interpreter object (state) for every thread, and leave thread management (mutexes, IPCs, etc) to an app?
Another alternative would be object locks, function locks, etc (an attribute like "locked"?).
If I've SMP machine (and this becomes common nowadays, at least for servers), it makes sense.
But I guess it would require very extensive rewriting of interpreter, or?
Regards, /Al
/ Brevbäraren