The TOC brainstorming
Alexander Gladysh
While we discussing the format and the license, please don't forget to
contribute to the TOC brainstorming page:
https://github.com/lua-cookbook/lua-cookbook/wiki/Table-of-Contents-Brainstorming
It surely needs some attention.
Also, can someone please improve The Purpose page?
https://github.com/lua-cookbook/lua-cookbook/wiki/The-Purpose
Thank you!
Alexander.
Peter Sommerfeld
I take it as that
for now, feel free to put it somewhere else.
I think native threads (os-threads) are not considered at all. Three
topics come to mind:
- Lua embedded in native threads.
- Differences/advantages/disadvantages of native threads and Lua
threads
- Different ways to integrate both / projects which do so (Lanes,
Rings etc)
May be that is a too advanced topic for a cookbook, but should be
mentioned
somewhere.
Peter
Alexander Gladysh
<pe...@sommerfeld-stur.at> wrote:
> Is this an adequate place to contribute to the brainstorming ? Well,
> I take it as that
> for now, feel free to put it somewhere else.
Sending contributions to the mailing list is fine. Alternatively, you
may want to add your topics to the end of the TOC wiki page (or even
directly in the section where you think they belong).
> I think native threads (os-threads) are not considered at all. Three
> topics come to mind:
> - Lua embedded in native threads.
> - Differences/advantages/disadvantages of native threads and Lua
> threads
> - Different ways to integrate both / projects which do so (Lanes,
> Rings etc)
> May be that is a too advanced topic for a cookbook, but should be
> mentioned
> somewhere.
No, I agree, this is a must have section.
Thank you!
Alexander.
steve donovan
<pe...@sommerfeld-stur.at> wrote:
> May be that is a too advanced topic for a cookbook, but should be
> mentioned somewhere.
Yes, it is an important topic. Even as an experienced Lua user, I get
confused by all the _options_ available for concurrent programming in
Lua. I like Lanes, but LuaJIT doesn't like Lanes as it is, and Asko
seems to have lost interest in it. (And works-with-luajit is going to
be increasingly important, and _everyone_ including mobile users will
have multiple cores soon.)
Such a section would explain why a patched interpreter like LuaThreads
is ultimately a dead-end, since one ends up with a Lua equivalent of
the Global Interpreter Lock.
(It would be interesting if Mike Pall got interested in concurrency,
because he would be sure to come up with an insanely efficient way of
doing it.)
steve d.
Alexander Gladysh
> On Tue, Jan 25, 2011 at 10:27 PM, Peter Sommerfeld
> <pe...@sommerfeld-stur.at> wrote:
>> May be that is a too advanced topic for a cookbook, but should be
>> mentioned somewhere.
> Yes, it is an important topic. Even as an experienced Lua user, I get
> confused by all the _options_ available for concurrent programming in
> Lua. I like Lanes, but LuaJIT doesn't like Lanes as it is, and Asko
> seems to have lost interest in it. (And works-with-luajit is going to
> be increasingly important, and _everyone_ including mobile users will
> have multiple cores soon.)
> Such a section would explain why a patched interpreter like LuaThreads
> is ultimately a dead-end, since one ends up with a Lua equivalent of
> the Global Interpreter Lock.
Yes. It should also explain that you should not even try to use more
than one thread from one Lua state. This is just a bad design.
Alexander.
Peter Sommerfeld
> Peter Sommerfeld wrote
> <pe...@sommerfeld-stur.at> wrote:
>> May be that is a too advanced topic for a cookbook, but should be
>> mentioned somewhere.
>
> Yes, it is an important topic. Even as an experienced Lua user, I get
> confused by all the _options_ available for concurrent programming in
> Lua.
That all is a rather advanced topic and I don't think it can be covered in
a cookcook in detail. Ma be such a structure is appropriate:
Concurrent Programming
----------------------
1 Coroutines
1.1 ...1.x as descriped in TOC
2. Lua in concurrent enviroment (options? problems?)
3 Coroutines and Native Threads
3.1 Overview
3.2 Feature Table of current solutions
3.3 Short discussion of solutions
The feature table should point out basic design decisions like platform,
interpreter constraints, communication, locking etc.
Alexander Gladysh wrote:
> Yes. It should also explain that you should not even try to usemore than
> one thread from one Lua state. This is just a bad design.
Hmmm, I see Lua running within native threads, not as master.
Anyway, I've just started to explore this area and cannot help here more.
These are just questions I would like to see answered. And my english is
too limited to participate at all.
Peter
Alexander Gladysh
<pe...@sommerfeld-stur.at> wrote:
> steve donovan wrote:
>> Peter Sommerfeld wrote
>> <pe...@sommerfeld-stur.at> wrote:
> Alexander Gladysh wrote:
>> Yes. It should also explain that you should not even try to usemore than
>> one thread from one Lua state. This is just a bad design.
> Hmmm, I see Lua running within native threads, not as master.
The proper way it is to get a pool of Lua states, a pool of worker
threads and a manager that dispatches incoming tasks between available
threads, using available states from the pool.
That being said, if I'm not on Windows or some limited embedded
platforms, I'd do with forks (that is, processes) instead of
multithreading.
> Anyway, I've just started to explore this area and cannot help here more.
Your feedback is most useful! I forgot the details about what it is to
start to explore these areas... and these details are needed to get
the book right.
> These are just questions I would like to see answered. And my english is
> too limited to participate at all.
Your English is good! :-)
Thank you!
Alexander.
Alexander Gladysh
<pe...@sommerfeld-stur.at> wrote:
> steve donovan wrote:
> That all is a rather advanced topic and I don't think it can be covered in
> a cookcook in detail. Ma be such a structure is appropriate:
> Concurrent Programming
> ----------------------
>
> 1 Coroutines
> 1.1 ...1.x as descriped in TOC
>
> 2. Lua in concurrent enviroment (options? problems?)
>
> 3 Coroutines and Native Threads
> 3.1 Overview
> 3.2 Feature Table of current solutions
> 3.3 Short discussion of solutions
>
> The feature table should point out basic design decisions like platform,
> interpreter constraints, communication, locking etc.
Thank you! I've incorporated some of your suggestions into V.6. Say if
I got something wrong.
Alexander.
Peter Sommerfeld
> The proper way it is to get a pool of Lua states, a pool of worker
> threads and a manager that dispatches incoming tasks between available
> threads, using available states from the pool.
I agree. That should be pointed out.
> That being said, if I'm not on Windows or some limited embedded
> platforms, I'd do with forks (that is, processes) instead of
> multithreading.
OK, but that is associated with some overhead (runtime,communications)
and is another topic. May be you should add this as option to the list
of concurrent programming although it does not belong into this topic
in a narrower sense.
I suspect Lua isn't that well suited for real multy-threading.
Probably a language has to be especially designed for that area
as it has been done with erlang. But as it has been said: a bird
in the hand is worth two in the bush. :-)
Peter
Alexander Gladysh
>> platforms, I'd do with forks (that is, processes) instead of
>> multithreading.
> OK, but that is associated with some overhead (runtime,communications)
> and is another topic.
You have to pay this overhead anyway, sooner or later. When you're not
on Windows or embedded, most likely you're on server-side and you will
need to scale out to another machine. If you're too tied in being
multithreaded, you're in trouble.
Also, not being multithreaded is much simpler.
> May be you should add this as option to the list
> of concurrent programming although it does not belong into this topic
> in a narrower sense.
Well, I'm not sure. I always thought that multithreaded programming is
a subset of concurrent programming.
Is there any kind of reference, so we can get the terminology right?
> I suspect Lua isn't that well suited for real multy-threading.
> Probably a language has to be especially designed for that area
> as it has been done with erlang.
Um. Erlang does not do OS-level threads (which you seem to call "real
multy-threading").
Also, even plain (non-JITted) Lua beats Erlang in concurrent
programming, performance-wise:
http://www.inf.puc-rio.br/~roberto/docs/ry08-05.pdf
> But as it has been said: a bird
> in the hand is worth two in the bush. :-)
Alexander.
Peter Sommerfeld
I'm not sure it is appropriate to discuss this on this list.
Anyway, you deserve an answer...
Alexander Gladysh wrote:
> Peter Sommerfeld wrote:
>> OK, but that is associated with some overhead (runtime,communications)
>> and is another topic.
>
> You have to pay this overhead anyway, sooner or later. When you're not
> on Windows or embedded, most likely you're on server-side and you will
> need to scale out to another machine. If you're too tied in being
> multithreaded, you're in trouble.
Probably. That all depends on the area of application. I think in
smaller dimensions, desktop, vps etc.
> Also, not being multithreaded is much simpler.
Sure!
> Well, I'm not sure. I always thought that multithreaded programming is
> a subset of concurrent programming.
> Is there any kind of reference, so we can get the terminology right?
??? I think that are different abstraction levels.
>> I suspect Lua isn't that well suited for real multy-threading.
>> Probably a language has to be especially designed for that area
>> as it has been done with erlang.
>
> Um. Erlang does not do OS-level threads (which you seem to call"real
> multy-threading").
It does. It distributes its processes onto mutible os-threads
in an smp enviroment, usually 1 os-thread per processor. You
can configure that at startup time.
> Also, even plain (non-JITted) Lua beats Erlang in concurrent
> programming, performance-wise:
>
> http://www.inf.puc-rio.br/~roberto/docs/ry08-05.pdf
I don't read that paper in this way. Anyway, benchmarks lie!
IMHO you cannot really compare Erlang and Lua, they are too
different. Erlang is huge, a sophisticated compiler, time
sliced scheduling, lots of features and libraries. It's a
Gorilla, Lua a fast and little long-tailed monkey...
I've done a bit of programming in Erlang and enjoyed it.
I come back to C++/Lua because it is not well suited for
lean and mean, easy desployable applications I'm more
iterested in.
Peter
Alexander Gladysh
On Wed, Jan 26, 2011 at 17:12, Peter Sommerfeld
<pe...@sommerfeld-stur.at> wrote:
> I'm not sure it is appropriate to discuss this on this list.
> Anyway, you deserve an answer...
Thanks :-)
> Alexander Gladysh wrote:
>> Peter Sommerfeld wrote:
>>> OK, but that is associated with some overhead (runtime,communications)
>>> and is another topic.
>> You have to pay this overhead anyway, sooner or later. When you're not
>> on Windows or embedded, most likely you're on server-side and you will
>> need to scale out to another machine. If you're too tied in being
>> multithreaded, you're in trouble.
> Probably. That all depends on the area of application. I think in
> smaller dimensions, desktop, vps etc.
Well, desktop outside of windows is of marginal usefulness. (Depends
on the niche though.)
And VPS *is* the first reason one has to scale out to several
machines. VPS servers are usually not that large.
Although, I may be spoiled by several years in high-load applications...
>> Well, I'm not sure. I always thought that multithreaded programming is
>> a subset of concurrent programming.
>> Is there any kind of reference, so we can get the terminology right?
> ??? I think that are different abstraction levels.
Well, yes. "Subset" in broad sense.
>>> I suspect Lua isn't that well suited for real multy-threading.
>>> Probably a language has to be especially designed for that area
>>> as it has been done with erlang.
>> Um. Erlang does not do OS-level threads (which you seem to call"real
>> multy-threading").
> It does. It distributes its processes onto mutible os-threads
> in an smp enviroment, usually 1 os-thread per processor. You
> can configure that at startup time.
I've got an impression that we were talking about user-controlled OS threads.
>> Also, even plain (non-JITted) Lua beats Erlang in concurrent
>> programming, performance-wise:
>> http://www.inf.puc-rio.br/~roberto/docs/ry08-05.pdf
> I don't read that paper in this way. Anyway, benchmarks lie!
Perhaps :-)
> IMHO you cannot really compare Erlang and Lua, they are too
> different. Erlang is huge, a sophisticated compiler, time
> sliced scheduling, lots of features and libraries. It's a
> Gorilla, Lua a fast and little long-tailed monkey...
Too different, of course.
But they play on the same field in the concurrent programming. (Albeit
Lua is somewhere in a far away corner now.)
> I've done a bit of programming in Erlang and enjoyed it.
> I come back to C++/Lua because it is not well suited for
> lean and mean, easy desployable applications I'm more
> iterested in.
Alexander.
Alexander Gladysh
> On Wed, Jan 26, 2011 at 17:12, Peter Sommerfeld
> <pe...@sommerfeld-stur.at> wrote:
>> I'm not sure it is appropriate to discuss this on this list.
>> Anyway, you deserve an answer...
Hmm, I did not realize this went to the list.
We should move to the private mail with this off-topic, sorry, everyone :-)
Alexander.