Re: asynchronous task communication

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Tue, 08 Jan 2013 18:18:44 +0000, Simon Wright wrote:

> Jeffrey Carter <spam.jrcarter.not@spam.not.acm.org> writes:
> 
>> On 01/08/2013 05:02 AM, Brian Drummond wrote:
> 
>>> So, holding onto a cursor would be unsafe (i.e. no longer refer to the
>>> original object) after an "insert" operation, possibly earlier in the
>>> vector?
>>
>> If you have an item in your (unbounded) array, indexed by Positive, at
>> index 3, it will still be at index 3 if you assign to components at
>> other indices, or extend the array by adding new components beyond the
>> current end of the array. However, if you insert a new component
>> before the existing item at index 3, then all the components after the
>> new component will shift up, and the existing item will then be at
>> index 4.
>>
>> This should be pretty obvious if you think about how you would
>> implement an unbounded array.
>>
>> One would think that a Cursor would behave similarly.
> 
> Not so! The Cursor becomes ambiguous[1], and using it is a bounded
> error. GNAT GPL 2012 implements Cursor using an Index, & behaves the way
> you'd expect.
> 
> [1] http://www.ada-auth.org/standards/12rm/html/RM-A-18-2.html#p240

Yep, cursor is a bad abstraction, with the semantics sometimes ill-defined. 
Pointers fall into same category.

On the contrary, index is a good abstraction for all ordered containers 
like arrays are. The semantics of index is well defined for all operations 
on the container.

For a graph or a tree, vector is an inappropriate interface because edges 
are usually enumerated in a different manner than vector does. So, if 
vectors should be used then rather privately. And if nodes of the graph 
need to be referenced then cursors or indices should again be used only 
privately.

Usually graphs require some reference counting schema when nodes are 
accessed with read and read-write accesses differentiated when graph should 
be updated. Furthermore read-write access may require cloning of nodes on 
demand preserving consistency of other views etc. It is not a simple issue, 
highly dependant on the problem space.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de