Re: Lanes 2008 revise

["Alexander Gladysh" <agladysh@...>]

> Alexander Gladysh kirjoitti 20.7.2008 kello 0:39:
>> On Sat, Jul 19, 2008 at 10:32 PM, Asko Kauppi <askok@dnainternet.net>
>> wrote:
>> ...
>> BTW, while we're on the docs: I'd like to see short thruoughtly
>> commented specific examples in each section -- at least so that I
>> would not need to scroll up to the "sample with communications" and
>> guess which is which.
> Samples will be runnable under 'tests/' and/or 'samples/' folders.

I mean inline samples in the docs.

>>>      • Lindas for all inter-thread communications (replaces FIFOs, tubes,
>>> thread groups)
>>
>> I'd place a link to some page, describing what Linda is in the docs
>> (or provide a short inline definition; better both). Is there a better
>> description than on Wikipedia?
>
> Oh, seems I've deleted a simple intro to Lindas - something like "they are a
> table of FIFO's, basically".  Would that do?  :)

With a minimal example -- yes.

>>>      • Fast inter-state copy using hidden "keeper states" (replaces
>>> serialization)
>>
>> Interesting. Care to elaborate?
>
> Shortly, it's what Mark Hamburg implied in one of his slide.

Is there a link or something?

> Instead of having a C-side managed queue of information (as Lanes 2007 used to do for
> send/receive), there's a pool of hidden Lua states that are used for keeping
> the data. Each Linda object maps to the same keeper state always. There are
> two inter-state copies for each data passing (A to keeper, keeper to B) but
> those copies are trivially fast (no serialization).
>
> Also, I now have code inside to copy closures (either C or Lua) which is
> ..hmm.. rather nice, indeed!
>
> The big part of this is allowing userdata to be shared by the lanes. It
> allows code like this:
>
> <<
>        local linda= lanes.linda()              -- communications for
> everyone
>
>        function A()
>                ...using 'linda' as an upvalue
>        end
>
>        function B()
>                ...using 'linda' as an upvalue
>        end
>
>        ...spawn A and B
>
>        ...use 'linda' as an upvalue
> <<
>
> In other words, the "normal" Lua upvalue scoping now extends also to
> multiple Lua states.  Voilà!  :)

Still confused. I guess, I'd have to look to Lanes sources :-)

>>>      • 'error' field for catching a lane's possible error
>>
>> Looks like error field implicitly makes it possible to detect lane
>> lifetime status (say, by adding manual error() call in the end).
>
> Actually, '.state' is for that.    "pending"/"running"/"waiting"  -->
> "done"/"error"/"cancelled"

Yes, I missed that, sorry.

>> Also
>> it looks weird to me. What is the intended usage scenario?
>
> Usually, reading results of an erroneous lane will propagate the error to
> the reading lane, at the time of reading. C# has a similar technique, and I
> have found it good.

I agree, that should be good.

> The use of '.error' is to sneak whether there is an error, without causing
> the propagation.  May be unnecessary; it is exactly for cases like this I'd
> like to get tests & discussion going.

Is it possible to do this reliably?

Alexander.