[ANN] Lua bindings for SDL 2.0

SDL Development
1

Hi,

I’m glad to announce that I start a Lua binding for SDL 2.0. For the
moment, I’m able to initialize SDL, create window, use timers and
such.

It will support Lua 5.2 only at first and maybe if I get more time I
will add support for Lua 5.1 but that’s not sure.

I plan to release it around mi september with all documentation. The
binding is written as C native code thus being very fast and portable.

Every component of SDL will be available except:

  • Shared library object support. It’s too complex to seek C symbols
    and execute them from Lua. This will requires FFI extension. Anyway, I
    don’t think this is relevant still the binding is for Lua, so users
    should not use C anymore :-).

Some component will be probably modified:

  • File RW ops, for instance, it may be difficult to map the memory
    managed RWops with Lua data. I will see how I can do that.

The binding tries to be as possible like the official library, so the
user does not need too much documentation to understand the binding.

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

If you want to see the progress you can go on the redmine:

https://redmine.malikania.fr/projects/luasdl2

And download the mercurial repository

http://hg.malikania.fr/LuaSDL2

Please note that nothing is committed yet, but I will do it in the evening.

Regards,–
Demelier David

2

2013/8/28 David Demelier <demelier.david at gmail.com>

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

Which, in Lua, is really nothing more than syntactical sugar for calling a
function with the object as its first parameter, so it’s still basically
the same =)

3

2013/8/28 Jonas Kulla :

2013/8/28 David Demelier <@David_Demelier>

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

Which, in Lua, is really nothing more than syntactical sugar for calling a
function with the object as its first parameter, so it’s still basically the
same =)

Yes, but from the C side it’s a bit different as you must create the
object with metatable while it’s not needed in pure Lua (but preferred
for __index).–
Demelier David

4

2013/8/28 David Demelier <@David_Demelier>:

Hi,

I’m glad to announce that I start a Lua binding for SDL 2.0. For the
moment, I’m able to initialize SDL, create window, use timers and
such.

It will support Lua 5.2 only at first and maybe if I get more time I
will add support for Lua 5.1 but that’s not sure.

I plan to release it around mi september with all documentation. The
binding is written as C native code thus being very fast and portable.

Every component of SDL will be available except:

  • Shared library object support. It’s too complex to seek C symbols
    and execute them from Lua. This will requires FFI extension. Anyway, I
    don’t think this is relevant still the binding is for Lua, so users
    should not use C anymore :-).

Some component will be probably modified:

  • File RW ops, for instance, it may be difficult to map the memory
    managed RWops with Lua data. I will see how I can do that.

The binding tries to be as possible like the official library, so the
user does not need too much documentation to understand the binding.

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

If you want to see the progress you can go on the redmine:

https://redmine.malikania.fr/projects/luasdl2

And download the mercurial repository

http://hg.malikania.fr/LuaSDL2

Please note that nothing is committed yet, but I will do it in the evening.

Regards,

I’m reaching the end of the binding. Unfortunately one feature will
also be missing for now, it’s threads & timer. As Lua is not really
thread safe I can’t find a good solution for adding SDL_CreateThread
and such functions.

However, a lot of functions are already implemented and starting
working like this example:

local SDL = require “SDL”

– Initialize SDL.
local ret, err = SDL.init{ SDL.flags.Video }

if not ret then
error(err)
end

– Create a window.
local win, err = SDL.createWindow{
name = “Text”,
width = 800,
height = 640,
x = 30,
y = 30,
flags = { SDL.window.OpenGL }
}

if not win then
error(err)
end

– Wait for events
local running = true

while running do
for e in SDL.pollEvent() do
if e.type == SDL.event.Quit then
running = false
elseif e.type == SDL.event.MouseMotion then
– Show mouse position
print(string.format(“Mouse x: %d, y: %d”, e.x, e.y))
elseif e.type == SDL.event.KeyDown and e.keysym.sym ==
SDL.keycode.Return then
print("—")
– Warp mouse on Return press!
win:warpMouse(50, 50)
end
end
end

I’m starting to write the documentation with LDoc, stay tuned :-).

Cheers,–
Demelier David

5

Wow, that is awesome!! Is the binding cross-platform, [eg build for windows, run on linux], or the binaries depend on the host??On Sep 2, 2013, at 3:57 PM, David Demelier <demelier.david at gmail.com> wrote:

2013/8/28 David Demelier <demelier.david at gmail.com>:

Hi,

I’m glad to announce that I start a Lua binding for SDL 2.0. For the
moment, I’m able to initialize SDL, create window, use timers and
such.

It will support Lua 5.2 only at first and maybe if I get more time I
will add support for Lua 5.1 but that’s not sure.

I plan to release it around mi september with all documentation. The
binding is written as C native code thus being very fast and portable.

Every component of SDL will be available except:

  • Shared library object support. It’s too complex to seek C symbols
    and execute them from Lua. This will requires FFI extension. Anyway, I
    don’t think this is relevant still the binding is for Lua, so users
    should not use C anymore :-).

Some component will be probably modified:

  • File RW ops, for instance, it may be difficult to map the memory
    managed RWops with Lua data. I will see how I can do that.

The binding tries to be as possible like the official library, so the
user does not need too much documentation to understand the binding.

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

If you want to see the progress you can go on the redmine:

https://redmine.malikania.fr/projects/luasdl2

And download the mercurial repository

http://hg.malikania.fr/LuaSDL2

Please note that nothing is committed yet, but I will do it in the evening.

Regards,

I’m reaching the end of the binding. Unfortunately one feature will
also be missing for now, it’s threads & timer. As Lua is not really
thread safe I can’t find a good solution for adding SDL_CreateThread
and such functions.

However, a lot of functions are already implemented and starting
working like this example:

local SDL = require “SDL”

– Initialize SDL.
local ret, err = SDL.init{ SDL.flags.Video }

if not ret then
error(err)
end

– Create a window.
local win, err = SDL.createWindow{
name = “Text”,
width = 800,
height = 640,
x = 30,
y = 30,
flags = { SDL.window.OpenGL }
}

if not win then
error(err)
end

– Wait for events
local running = true

while running do
for e in SDL.pollEvent() do
if e.type == SDL.event.Quit then
running = false
elseif e.type == SDL.event.MouseMotion then
– Show mouse position
print(string.format(“Mouse x: %d, y: %d”, e.x, e.y))
elseif e.type == SDL.event.KeyDown and e.keysym.sym ==
SDL.keycode.Return then
print("—")
– Warp mouse on Return press!
win:warpMouse(50, 50)
end
end
end

I’m starting to write the documentation with LDoc, stay tuned :-).

Cheers,

–
Demelier David

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

6

2013/9/2 :

Wow, that is awesome!! Is the binding cross-platform, [eg build for windows, run on linux], or the binaries depend on the host??

Hi, thanks for your comment.

I’m one of the people who really love to do write portable program.
Usually I never use non-portable code. Here the bindings only refers
to SDL functions and some of the ANSI C standard, except snprintf but
this one is available on Windows.

I didn’t compiled it on Windows yet but it will be done in the next
few days. I will provide binaries for Windows 32 and 64 bits. However
for Linux and other unix systems, I let the maintainer of the
distribution to compile the package himself.

So no, the binding is not cross platform as it is and you will need a
SDL binding for every operating system, but in Lua it’s really common
to have this as it’s a very small language that does not support
foreign interfaces like python has with ctypes.

But don’t be afraid, as I said, binaries for Windows will be available
easily :-). Also for Linux you just need CMake + SDL 2.0. It compiles
in less than 10 seconds.

Cheers,> On Sep 2, 2013, at 3:57 PM, David Demelier <@David_Demelier> wrote:

2013/8/28 David Demelier <@David_Demelier>:

Hi,

I’m glad to announce that I start a Lua binding for SDL 2.0. For the
moment, I’m able to initialize SDL, create window, use timers and
such.

It will support Lua 5.2 only at first and maybe if I get more time I
will add support for Lua 5.1 but that’s not sure.

I plan to release it around mi september with all documentation. The
binding is written as C native code thus being very fast and portable.

Every component of SDL will be available except:

  • Shared library object support. It’s too complex to seek C symbols
    and execute them from Lua. This will requires FFI extension. Anyway, I
    don’t think this is relevant still the binding is for Lua, so users
    should not use C anymore :-).

Some component will be probably modified:

  • File RW ops, for instance, it may be difficult to map the memory
    managed RWops with Lua data. I will see how I can do that.

The binding tries to be as possible like the official library, so the
user does not need too much documentation to understand the binding.

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

If you want to see the progress you can go on the redmine:

https://redmine.malikania.fr/projects/luasdl2

And download the mercurial repository

http://hg.malikania.fr/LuaSDL2

Please note that nothing is committed yet, but I will do it in the evening.

Regards,

I’m reaching the end of the binding. Unfortunately one feature will
also be missing for now, it’s threads & timer. As Lua is not really
thread safe I can’t find a good solution for adding SDL_CreateThread
and such functions.

However, a lot of functions are already implemented and starting
working like this example:

local SDL = require “SDL”

– Initialize SDL.
local ret, err = SDL.init{ SDL.flags.Video }

if not ret then
error(err)
end

– Create a window.
local win, err = SDL.createWindow{
name = “Text”,
width = 800,
height = 640,
x = 30,
y = 30,
flags = { SDL.window.OpenGL }
}

if not win then
error(err)
end

– Wait for events
local running = true

while running do
for e in SDL.pollEvent() do
if e.type == SDL.event.Quit then
running = false
elseif e.type == SDL.event.MouseMotion then
– Show mouse position
print(string.format(“Mouse x: %d, y: %d”, e.x, e.y))
elseif e.type == SDL.event.KeyDown and e.keysym.sym ==
SDL.keycode.Return then
print("—")
– Warp mouse on Return press!
win:warpMouse(50, 50)
end
end
end

I’m starting to write the documentation with LDoc, stay tuned :-).

Cheers,

–
Demelier David

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Demelier David

7

Good to hear that, thanks!On Sep 2, 2013, at 5:42 PM, David Demelier <demelier.david at gmail.com> wrote:

2013/9/2 <@Aggelos_Kolaitis>:

Wow, that is awesome!! Is the binding cross-platform, [eg build for windows, run on linux], or the binaries depend on the host??

Hi, thanks for your comment.

I’m one of the people who really love to do write portable program.
Usually I never use non-portable code. Here the bindings only refers
to SDL functions and some of the ANSI C standard, except snprintf but
this one is available on Windows.

I didn’t compiled it on Windows yet but it will be done in the next
few days. I will provide binaries for Windows 32 and 64 bits. However
for Linux and other unix systems, I let the maintainer of the
distribution to compile the package himself.

So no, the binding is not cross platform as it is and you will need a
SDL binding for every operating system, but in Lua it’s really common
to have this as it’s a very small language that does not support
foreign interfaces like python has with ctypes.

But don’t be afraid, as I said, binaries for Windows will be available
easily :-). Also for Linux you just need CMake + SDL 2.0. It compiles
in less than 10 seconds.

Cheers,

On Sep 2, 2013, at 3:57 PM, David Demelier <demelier.david at gmail.com> wrote:

2013/8/28 David Demelier <demelier.david at gmail.com>:

Hi,

I’m glad to announce that I start a Lua binding for SDL 2.0. For the
moment, I’m able to initialize SDL, create window, use timers and
such.

It will support Lua 5.2 only at first and maybe if I get more time I
will add support for Lua 5.1 but that’s not sure.

I plan to release it around mi september with all documentation. The
binding is written as C native code thus being very fast and portable.

Every component of SDL will be available except:

  • Shared library object support. It’s too complex to seek C symbols
    and execute them from Lua. This will requires FFI extension. Anyway, I
    don’t think this is relevant still the binding is for Lua, so users
    should not use C anymore :-).

Some component will be probably modified:

  • File RW ops, for instance, it may be difficult to map the memory
    managed RWops with Lua data. I will see how I can do that.

The binding tries to be as possible like the official library, so the
user does not need too much documentation to understand the binding.

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

If you want to see the progress you can go on the redmine:

https://redmine.malikania.fr/projects/luasdl2

And download the mercurial repository

http://hg.malikania.fr/LuaSDL2

Please note that nothing is committed yet, but I will do it in the evening.

Regards,

I’m reaching the end of the binding. Unfortunately one feature will
also be missing for now, it’s threads & timer. As Lua is not really
thread safe I can’t find a good solution for adding SDL_CreateThread
and such functions.

However, a lot of functions are already implemented and starting
working like this example:

local SDL = require “SDL”

– Initialize SDL.
local ret, err = SDL.init{ SDL.flags.Video }

if not ret then
error(err)
end

– Create a window.
local win, err = SDL.createWindow{
name = “Text”,
width = 800,
height = 640,
x = 30,
y = 30,
flags = { SDL.window.OpenGL }
}

if not win then
error(err)
end

– Wait for events
local running = true

while running do
for e in SDL.pollEvent() do
if e.type == SDL.event.Quit then
running = false
elseif e.type == SDL.event.MouseMotion then
– Show mouse position
print(string.format(“Mouse x: %d, y: %d”, e.x, e.y))
elseif e.type == SDL.event.KeyDown and e.keysym.sym ==
SDL.keycode.Return then
print("—")
– Warp mouse on Return press!
win:warpMouse(50, 50)
end
end
end

I’m starting to write the documentation with LDoc, stay tuned :-).

Cheers,

–
Demelier David

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Demelier David

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

8

Message-ID:
<CAO+PfDeorPMrNUULve14wY8mgY73shZdV+mv1o7meHkZwXR_rA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2013/8/28 David Demelier <demelier.david at gmail.com>:

Hi,

I’m glad to announce that I start a Lua binding for SDL 2.0. For the
moment, I’m able to initialize SDL, create window, use timers and
such.

The binding tries to be as possible like the official library, so the
user does not need too much documentation to understand the binding.

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

Please note that nothing is committed yet, but I will do it in the
evening.

Regards,

I’m reaching the end of the binding. Unfortunately one feature will
also be missing for now, it’s threads & timer. As Lua is not really
thread safe I can’t find a good solution for adding SDL_CreateThread
and such functions.

Where exactly is the problem? Is it something that can be solved by
just having two LUA contexts and performing data marshaling of some
sort between them? If so, them you might look at C++11’s threading
support. The details will presumably be wrong, but the basic outlines
(e.g. futures, an object to encapsulate the actual idea of a thread,
etc.) might be useful.> Date: Mon, 2 Sep 2013 14:57:54 +0200

From: David Demelier <demelier.david at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] [ANN] Lua bindings for SDL 2.0

9

2013/9/3 Jared Maddox :>> Date: Mon, 2 Sep 2013 14:57:54 +0200

From: David Demelier <@David_Demelier>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] [ANN] Lua bindings for SDL 2.0
Message-ID:
<CAO+PfDeorPMrNUULve14wY8mgY73shZdV+mv1o7meHkZwXR_rA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

2013/8/28 David Demelier <@David_Demelier>:

Hi,

I’m glad to announce that I start a Lua binding for SDL 2.0. For the
moment, I’m able to initialize SDL, create window, use timers and
such.

The binding tries to be as possible like the official library, so the
user does not need too much documentation to understand the binding.

However, some parts will be object oriented. For instance, when you
create a window, you use method on this window rather than function
taking the window as first parameter.

Please note that nothing is committed yet, but I will do it in the
evening.

Regards,

I’m reaching the end of the binding. Unfortunately one feature will
also be missing for now, it’s threads & timer. As Lua is not really
thread safe I can’t find a good solution for adding SDL_CreateThread
and such functions.

Where exactly is the problem? Is it something that can be solved by
just having two LUA contexts and performing data marshaling of some
sort between them? If so, them you might look at C++11’s threading
support. The details will presumably be wrong, but the basic outlines
(e.g. futures, an object to encapsulate the actual idea of a thread,
etc.) might be useful.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

The problem is that binding SDL.createThread will require to create a
new lua_State and then you will not able to share data from the
current script and the thread, so I think this pretty useless.

For example, using the same Lua state like that:

local global = 0

local t = SDL.createThread(
function ()
print "Incrementing global"
global = global + 1
SDL.delay(100)
end

while true do
SDL.waitEvent()
end

will immediately fail because waitEvent() will work on the same Lua
state as the thread and segfault. However, when calling
SDL.createThread() the C function can call lua_dump and lua_load to
get the function passed to the createThread() function. It worked, I
already tried that, but then the global is not shared anymore and the
thread sounds pretty useless to me.

Maybe there is a way to share data from a Lua state to an other state?
If it’s possible maybe we can add a optional data to the
SDL.createThread function as the second parameter.

Cheers,

–
Demelier David

10

Message-ID:
<CAO+PfDczcA9KJn=YxpUFa16KP37EEDvs22R72Nbp6vs=YdZwbg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

The problem is that binding SDL.createThread will require to create a
new lua_State and then you will not able to share data from the
current script and the thread, so I think this pretty useless.

Actually, I was sort-of suggesting this. I definitely think you should
provide atomic queues for threads if you add the threading capability.
That isn’t to say that I don’t have some rough idea of how to solve
the following conundrum:

For example, using the same Lua state like that:

local global = 0

local t = SDL.createThread(
function ()
print "Incrementing global"
global = global + 1
SDL.delay(100)
end

while true do
SDL.waitEvent()
end

will immediately fail because waitEvent() will work on the same Lua
state as the thread and segfault. However, when calling
SDL.createThread() the C function can call lua_dump and lua_load to
get the function passed to the createThread() function. It worked, I
already tried that, but then the global is not shared anymore and the
thread sounds pretty useless to me.

This requires a slight change in semantics. In LPC, the OO conceit
behind the design is that an object represents a program. I’d suggest
the same: name the relevant function set in such a way that it becomes
clear that globals won’t be carried over (though, without looking
deeper than I have, I can’t say that it’s impossible: it’s been
several years since I looked at Lua, and I’ve never actually used it).

To fill your globals and singletons needs I’d actually suggest an
"atomic table", implemented with userdata, SDL’s atomics, and maybe
Lua’s conventional table implementation if you can pull it loose
enough. Operations would presumably include “set”, “get”, and if
possible “copy”, though that last one might or might not work out
well. Data that’s supposed to be viewable from multiple SDL threads
would just need to be stored into an atomic table that’s shared with
the SDL thread being talked to.

Unfortunately, all of this might require some sort of complication in
the system that I can’t really predict, since I’m not actually
familiar with the Lua API. Something to pay attention to in particular
is the interaction with the garbage collection: if it isn’t designed
for multi-threading environments then I’d suggest abandoning my advise
as impractical.> Date: Tue, 3 Sep 2013 12:25:02 +0200

From: David Demelier <demelier.david at gmail.com>
To: SDL Development List
Subject: Re: [SDL] [ANN] Lua bindings for SDL 2.0

11

L?VE (https://love2d.org, uses SDL 1.2 / 2.0) implements threads as separate Lua states. The latest version uses something similar to Go’s channels for inter-thread communication and data copying.

https://www.love2d.org/wiki/Channel

It’s obviously more limited than full state sharing between threads, but I don’t think that option is practical for Lua. There’s still room for adding some sort of larger userdata object to L?VE for storing “shared” values, I think. LuaJIT’s FFI creates more opportunities as well.

You can see all the code here: https://bitbucket.org/rude/love/src/tip/src/modules/thread?at=defaultOn 2013-09-04, at 2:40 AM, Jared Maddox wrote:

Date: Tue, 3 Sep 2013 12:25:02 +0200
From: David Demelier <demelier.david at gmail.com>
To: SDL Development List
Subject: Re: [SDL] [ANN] Lua bindings for SDL 2.0
Message-ID:
<CAO+PfDczcA9KJn=YxpUFa16KP37EEDvs22R72Nbp6vs=YdZwbg at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

The problem is that binding SDL.createThread will require to create a
new lua_State and then you will not able to share data from the
current script and the thread, so I think this pretty useless.

Actually, I was sort-of suggesting this. I definitely think you should
provide atomic queues for threads if you add the threading capability.
That isn’t to say that I don’t have some rough idea of how to solve
the following conundrum:

For example, using the same Lua state like that:

local global = 0

local t = SDL.createThread(
function ()
print "Incrementing global"
global = global + 1
SDL.delay(100)
end

while true do
SDL.waitEvent()
end

will immediately fail because waitEvent() will work on the same Lua
state as the thread and segfault. However, when calling
SDL.createThread() the C function can call lua_dump and lua_load to
get the function passed to the createThread() function. It worked, I
already tried that, but then the global is not shared anymore and the
thread sounds pretty useless to me.

This requires a slight change in semantics. In LPC, the OO conceit
behind the design is that an object represents a program. I’d suggest
the same: name the relevant function set in such a way that it becomes
clear that globals won’t be carried over (though, without looking
deeper than I have, I can’t say that it’s impossible: it’s been
several years since I looked at Lua, and I’ve never actually used it).

To fill your globals and singletons needs I’d actually suggest an
"atomic table", implemented with userdata, SDL’s atomics, and maybe
Lua’s conventional table implementation if you can pull it loose
enough. Operations would presumably include “set”, “get”, and if
possible “copy”, though that last one might or might not work out
well. Data that’s supposed to be viewable from multiple SDL threads
would just need to be stored into an atomic table that’s shared with
the SDL thread being talked to.

Unfortunately, all of this might require some sort of complication in
the system that I can’t really predict, since I’m not actually
familiar with the Lua API. Something to pay attention to in particular
is the interaction with the garbage collection: if it isn’t designed
for multi-threading environments then I’d suggest abandoning my advise
as impractical.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

12

L?VE (https://love2d.org, uses SDL 1.2 / 2.0) implements threads as
separate Lua states. The latest version uses something similar to Go’s
channels for inter-thread communication and data copying.

https://www.love2d.org/wiki/Channel

It’s obviously more limited than full state sharing between threads, but
I don’t think that option is practical for Lua. There’s still room for
adding some sort of larger userdata object to L?VE for storing "shared"
values, I think. LuaJIT’s FFI creates more opportunities as well.

You can see all the code
here: https://bitbucket.org/rude/love/src/tip/src/modules/thread?at=default

mailto:David_Demelier>
<mailto:sdl at lists.libsdl.org>>
Message-ID:
<CAO+PfDczcA9KJn=YxpUFa16KP37EEDvs22R72Nbp6vs=YdZwbg at mail.gmail.com
<mailto:CAO+PfDczcA9KJn=YxpUFa16KP37EEDvs22R72Nbp6vs=YdZwbg at mail.gmail.com>>
Content-Type: text/plain; charset=UTF-8

The problem is that binding SDL.createThread will require to create a
new lua_State and then you will not able to share data from the
current script and the thread, so I think this pretty useless.

Actually, I was sort-of suggesting this. I definitely think you should
provide atomic queues for threads if you add the threading capability.
That isn’t to say that I don’t have some rough idea of how to solve
the following conundrum:

For example, using the same Lua state like that:

local global = 0

local t = SDL.createThread(
function ()
print "Incrementing global"
global = global + 1
SDL.delay(100)
end

while true do
SDL.waitEvent()
end

will immediately fail because waitEvent() will work on the same Lua
state as the thread and segfault. However, when calling
SDL.createThread() the C function can call lua_dump and lua_load to
get the function passed to the createThread() function. It worked, I
already tried that, but then the global is not shared anymore and the
thread sounds pretty useless to me.

This requires a slight change in semantics. In LPC, the OO conceit
behind the design is that an object represents a program. I’d suggest
the same: name the relevant function set in such a way that it becomes
clear that globals won’t be carried over (though, without looking
deeper than I have, I can’t say that it’s impossible: it’s been
several years since I looked at Lua, and I’ve never actually used it).

To fill your globals and singletons needs I’d actually suggest an
"atomic table", implemented with userdata, SDL’s atomics, and maybe
Lua’s conventional table implementation if you can pull it loose
enough. Operations would presumably include “set”, “get”, and if
possible “copy”, though that last one might or might not work out
well. Data that’s supposed to be viewable from multiple SDL threads
would just need to be stored into an atomic table that’s shared with
the SDL thread being talked to.

Unfortunately, all of this might require some sort of complication in
the system that I can’t really predict, since I’m not actually
familiar with the Lua API. Something to pay attention to in particular
is the interaction with the garbage collection: if it isn’t designed
for multi-threading environments then I’d suggest abandoning my advise
as impractical.

SDL mailing list
SDL at lists.libsdl.org <mailto:SDL at lists.libsdl.org>
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Hi,

Thanks, this looks really interesting! I will get a look an go further
in it.

For the moment I’m in the audio part, it’s the hardest for me since I
never use that one before and it uses intensively callbacks and raw data
which need more wrapper around Lua.

Cheers,On 04.09.2013 07:54, Alex Szpakowski wrote:

On 2013-09-04, at 2:40 AM, Jared Maddox <absinthdraco at gmail.com <mailto:absinthdraco at gmail.com>> wrote:

Date: Tue, 3 Sep 2013 12:25:02 +0200
From: David Demelier <@David_Demelier
To: SDL Development List <sdl at lists.libsdl.org
Subject: Re: [SDL] [ANN] Lua bindings for SDL 2.0