On 5/17/07, Sven Suska <sven715rt / suska.org> wrote:
> Hello,
>
Interesting idea Sven, I lose you on some points though

> in this post, I'd like to make a proposal to contribute
> to Ruby's fitness for the challenges of parallelization.
>
> The problem with sharing objects between threads
> is concurrent write access.
> If the objects were frozen,
> everything would be OK ... but also boring. :)
>
> Now, I think it should be possible
> to freeze the "already existing" data of an object
> and at the same time leave it open for "further growth".
> Especially, I have Hashes and Arrays in mind:
> New key/value pairs could be added to Hashes,
> objects could be appended to Arrays.
>
> So, I think it would be beneficial to introduce a third state of objects
> between frozen and normal, like "growing" or "crystallizing" or
> "monotonous" or "incrementally_freezing" or "partially_frozen" ...
>
> In this state, all methods that would
> modify the already "crystallized" data of the object
> should throw an exception.
> E.g. for strings, only appending would be allowed.
>
> Perhaps it would help implementing this idea,
> if the << method would be made special
> and be the only accepted modifying method
> in the "growing" state.

Hmm maybe that has something to do with your "permanent" methods, of
which I fail to grasp the idea right now.
Assuming that << is the only writing method to a semi-frozen object we
would need to freeze the methods on the object, like pulling them into
the object and disallow method lookup. Maybe it is not the best idea
to control the state at that global level?
>
> Also, it would probably be good to have a means of determining
> if a method call is safe to use, in the sense
> that its result will always be the same object,
You mean that the receiver will not be modified, right?
> regardless of what other threads do to the receiver.
> (Let's say, it is a "permanent" method call)
Non modifiying?
>
> Roughly:
> - when the receiving object is frozen, all method calls are "permanent"
Yes I guess I see what you mean with "permanent"
>
> - when the receiver is in the normal (unrestricted) state,
>   method calls are "permanent", iff the receiver is an immediate value.
Nope I am losing you, there are still non modifying methods as e.g.
to_s so I guess I am wrong in my understanding.
>
> - when the object is in the "growing" state, then it's a bit tricky:
>
>   Just having an array "permanent_methods" would not always work,
>   because there are methods that are both,
>   "permanent" or not, depending on the arguments.
Would you mind to elaborate?
>
>   For example, we would definitely want to use Array#[],
>   but this is only "permanent" for non-negative indices.
You mean because -1 would be different because of growing might occur
in a different thread. In that case permanent would mean insensible to
growth?
>
>   Perhaps, there could be some annotation to those methods,
>   (raising an exception if the call would not guarantee a permanent result),
I see, makes sense.
>   and this would only be switched on if the object is in the
> "crystallizing" state
>   (and the general check for "permanentness" were switched on, say
> globally).
>
> OK, let me stop here, for now.
> Has a similar idea been discussed before?
Not to my memories, but I hope this will become a rich one:)
>
>
> Regards,
> Sven
>
Cheers
Robert
>


-- 
You see things; and you say Why?
But I dream things that never were; and I say Why not?
-- George Bernard Shaw