[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lanes 2008 revise
- From: "Alexander Gladysh" <agladysh@...>
- Date: Sun, 20 Jul 2008 17:50:30 +0400
> 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.