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...
In general, efficient garbage collection on heavily threaded systems is difficult (although not impossible). The reference counts can be viewed as an implementation detail of the garbage collector (although they also have more visible side effects, such as deterministic destruction of object that go out of scope).
/ Niels Möller (vässar rödpennan)
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