Threads in 0.9.0?

[bartbes]

I think blocking with :demand() on a named channel should do the trick

No reason it has to be named.

2. :demand() is implemented in "smart" C++ (vs. long polling), right?

Yes, the thread calling demand is asleep.

3. Can I somehow build an atomic "tryDemand" method?

As you already found out, this is (mostly) what pop does.

If I may only supply flat tables (via Thread.run and channels), how do I make threads cooperatively work on a list of entities?

Push all the entries, and let each thread just take things from the channel until it's empty?

I believe the limit for number of channels is pretty high.

There is none enforced, so that should be pretty high.

Code: Select all

local meta = love.thread.getChannel("meta")
local keys = {}
for k,v in pairs( ent ) do
  love.thread.getChannel(k):push(v)
  keys[#keys+1] = k
end
meta:supply( keys )
for _,k in ipairs( keys ) do
  love.thread.getChannel(k):clear()
end

Why would you not just push all anonymous channels instead, or supply a table of them, instead of their names? Generally speaking you should be using as little named channels as possible (since they're basically globals).

Having a way to share actual tables would still be much better.

Unfortunately lua tables can't handle this well at all, which is the reason love has a message-passing based API.

And I believe every OS has a method to share RAM between processes (or at least threads)

Memory is shared in threads, always. That said, lua code lives separately, and only love userdata is shared. (Indeed the lua code only ever has a reference, and not the userdata itself.)

[Azhukar]

Push all the entries, and let each thread just take things from the channel until it's empty?

I believe he meant something akin to several threads working over the same array, for example the same 2D map.

[s-ol]

Push all the entries, and let each thread just take things from the channel until it's empty?

I believe he meant something akin to several threads working over the same array, for example the same 2D map.

Yes. Pushing a deep table like a Player entity with position vectors and child entities is neither fun nor performant like this.

[bartbes]

Then serialise.

[parallax7d]

just wondering, are threads and channels really lua lanes and lindas? if so this is cool cause i didn't want to install lanes since it looks like you had to recompile lua, and I didn't know if that version would be compatable with love and still be portable.

[slime]

just wondering, are threads and channels really lua lanes and lindas? if so this is cool cause i didn't want to install lanes since it looks like you had to recompile lua, and I didn't know if that version would be compatable with love and still be portable.

No – Channels are custom objects which use a queue data structure and concurrency concepts like condition variables. Thread objects just wrap operating system-level threads and load an independent Lua state.

[parallax7d]

so threads are like lua threads? concurrent but not parallel? And channels are like lindas, just a seperate os thread with it's own copy of lua? aka parallel but impossible to schedule?

[slime]

No, love's threads are real operating system threads - concurrent, parallel, and preemptive (when the system is capable.) They aren't really like Lua's coroutines, which have other uses.
Channels aren't their own threads at all, they're queue objects that let you communicate / pass data around between love threads (including making a thread wait for data.)

A typical use-case is to have a love thread and the main thread both using the same Channel, the love thread has code that calculates some value which it pushes to the Channel, and the main thread gets the value via [wiki]Channel:pop[/wiki].

Channel objects have a lot in common with Go's Channels.

[s-ol]

-snip-

And I believe every OS has a method to share RAM between processes (or at least threads)

Memory is shared in threads, always. That said, lua code lives separately, and only love userdata is shared. (Indeed the lua code only ever has a reference, and not the userdata itself.)

So each thread has their own LUA context (or whatever it's called)... Makes sense to prevent race-conditions Inguess but its kind of unfortunate for performance in this manner.

What if there was a table replacement userdata, couldn't you share the reference between threads?
Or a cross-context-reference-userdata? (I don't know the limitations of contexts and userdata)
Something like:

Code: Select all

local deepTable = { a={ 1, 2, 3 } }
local chan = love.thread.get channel("chan")
chan.push( love.thread.newReference( deepTable ) )

-- in code far far away
local var = chan.pop().getValue() -- or even:
local var = chan.pop()

var.a[2] = 13

Basically a userdata wrapper for lua tables or a general value-wrapper that overloads every operation by calling the appropriate action in the other lua context.

Edit: I read up on userdata a tiny bit and it seems you would have to create the reference userdata as the metatable of an empty table and overwrite all metamethods. You of course cannot modify the metatable but that would be a very small limitation.

[parallax7d]

thanks slime, that helps clarify things. Also, thank you to the devs for making love threads in the first place, not having to mess with Lanes is so convenient!