lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 


I've opened a lanes-developers mailing list at:	

http://luaforge.net/mail/?group_id=265
It'll take some more hours to activate, though. Detailed technical discussions are better held there, whereas for user-level comment I feel the main Lua list to be adequate, for now. 

Responses to Alexander's questions are below.


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.


Neither unpack() nor results() does not suggest that the function
"makes sure lane has finished" (i.e. blocking behaviour).

Also I consider mix of lane handle and lane results to be harmful. I'd
suggest to change it as follows:

local f = lanes.new(function(<...>) <...> end)
local lane_h = f(<...>)
local results = { lane_h:join(<timeout>) } -- Borrowing term from pthreads.
I like the join name there. Ultimately, it would be neat to have the global 'unpack()' be able to handle this, but it currently cannot.
• 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? :) 



Also I'd like to see more elaborate section on data passing,
explaining performance issues etc.


Okay. But...
Data passed between separate states (either as starting parameters, return values, upvalues or via Lindas) must conform to the following:
• booleans, numbers, strings, light userdata, functions and tables of those (including subtables, but without cycles!) can be passed 
	• duplicate references in tables are 'opened' (passed by value)
• table's metatables are not copied (doing so would cause a new mt for each copy, which seems clumsy) • function upvalues are copied by value (changing an upvalue is not mirrorred in other states) • full userdata can be passed if it's prepared using the 'luaG_shared()' system, which handles its lifespan management 
	• coroutines cannot be passed
About performance there's not much to say. Yet. On some machines it seems so fast I didn't think it actually ran! :) 




      • 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. 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à! :) 




      • '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" 



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.
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. 


Am I right that unpack() (as well as indexing the handle) on error in
lane would throw the same error into the main state? If so, then it is
probably better to resort to good old pcall() family and, possibly,
add lane status query a-la coroutine.status().


Yes. You just missed '.state' (which will get renamed to '.status').
The changes are BIG. Basically, only the underlying threading part (OS specific things) has remained fairly intact. Everything about the internals is redone, in good Lua remaking fashion (if you can live without it, throw 
it away).


Is the Lanes library (given apparent fiddling with debug library)
still compatible with LuaJIT?
The fiddling with debug is minor, and can be removed without sacrificing essential features. 

So, it should be doable to work with LuaJIT.





Lindas provide a wealth of opportunities for any kinds of inter-state
communication needs. Now, what I'd very much like, is to have a group of interested people help me fine tune the API's, before we make this truly public. Having a go with Lanes in some real world projects would soon show places where the API is suboptimal, and needs for features that are not 
currently there.


Please forgive me this question, but is there at least one (real
world) project that use Lanes 2008?


Sorry to say, but no.
This has been a more like "academic" endeavour from my side, wanting to see how well Lua will fit in multicore. It all started when we bought the Core Duo Macbook. :)
Aside from that, Lanes 2008 definately aims at being as "de facto" tool as LuaSocket is in its own arena. There's too much variation on multithreading toolkits out there right now (imho). 

This is exactly why I need outside help in this stage.

-asko