From: kjana@... (YANAGAWA Kazuhisa) Date: 2001-02-13T23:29:37+09:00 Subject: [ruby-talk:10782] Re: Suggestion for threading model In message spwhite@chariot.net.au writes: > Here's a possible implementation: (snipped ....) > This would incur the cost of one C style variable check per object reference > and slow method calls would have an additional context switch. I understand your proposal as a naive concurrent object model --- every object behave as a server or something like an actor, which processes request messages one at a time --- with more realistic and probably more efficient implementation. In that line, a program can be seen as constructed from normal threads and static objects. Threads of control does not belongs to any objects, and an object are not an active entity but an aggregate of static data and opertions on data. > > 3. Most important one: Is that model really so useful? > > I don't know. It would depend on the situation. This scheme doesn't help > with OS threads or multiple CPUs but it does have the advantage of being > automagic. :) With above assumption, then again, why we choose a model that is far from an internal implementation, which has contraversely a well-fit model? It doesn't depends on wheather threading is implemented in kernel, which relatively heavy weight, or user level library realizing very light weight and optimized for ultra fine grain threads like stack threads. I personally think a current programming model, where no implicit parallelism, is good enough, and what actually needed is well designed synchronization mechanism and easy-to-use libraries around it --- for example a mix-in module for implemtnting a monitor, a barrier like construct to wait multiple threads each other, library providing more fine grain constraints on method calls, etc. # Do not seriously recieve that fire-and-forget type of words :-P I # don't think so deep yet.... -- kjana@os.xaxon.ne.jp February 13, 2001 He knows most who speaks least.