Personally, I would prefer to have complete control over object locking, instead of delegating this task to "too smart" interpreter
The you really need another language than pike. Such as C.
Java (at least when using suns JRE) does not count, it cannot use more than one CPU:s in practical tests I found using google. I guess it does automatic locking when allocating or deallocating objects (which happens all the time (r)) and thus does not really scale.
Most threaded C-applications also tend not to scale to multiple CPU:s, actually.
/ Per Hedbor ()
Previous text:
2004-02-03 12:52: Subject: Re: Default backend and thread backends?
On Tue, Feb 03, 2004 at 12:35:04PM +0100, Per Hedbor () @ Pike (-) developers forum wrote:
Now, consider having a LOCK for each reference count change in pike (this is basically what hubbe implemented). You get severe slowdowns.
Well... Then it makes no sense, of course.
And I am going to think that languages like Pike (i.e. any where reference counting is used so heavily) are not well suited for multithreading...
OTOH, in case if interpreter state will be thread-local, and only few objects may be used for IPC/ITC, it still makes sense, or?
Personally, I would prefer to have complete control over object locking, instead of delegating this task to "too smart" interpreter engine, which tries to guess what I need/want and to save me from my own mistakes :)
Regards, /Al
/ Brevbäraren