RE: Lua Event driven programming

["John Hind" <john.hind@...>]

The epiphany I had in using Lua was to treat it as it is intended i.e. as an
embedded language. This means you can code both "above" and "below" the Lua
runtime engine. Furthermore you can use the Lua API as a kind of toolkit in
C, for example by using the registry table as a universal data-structure for
C which never gets exposed on the Lua side but can hold Lua variables and
objects.

This means it is easy to write a completely event driven architecture where
the events are defined by the API in C and the responses to the events are
provided by the application coder in Lua. You build a kind of simple
scheduler "above" lua which runs Lua functions serially (so no
multi-threading problems). The scheduler can be queued, timed, priority
driven, whatever, and functions can be queued either in C responding to
external events or pushed up from Lua application code (for example timed
execution).

With this structure, if you are consuming asynchronous events from multiple
threads, you can easily serialise them "above" Lua so the Lua environment
remains single-threaded.

Steve's suggestion below does this by using the message queue of the hidden
window to serialise the events, but the above is a more generic and flexible
way of achieving the same thing. Of course, in either case we are assuming
the event handlers terminate in a finite time and if necessary you can
enforce that using a watchdog thread.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br
[mailto:lua-bounces@bazar2.conectiva.com.br] On Behalf Of steve donovan
Sent: 02 June 2009 09:13
To: Lua list
Subject: Re: Lua Event driven programming

On Tue, Jun 2, 2009 at 3:21 AM, RJP Computing <rjpcomputing@gmail.com>
wrote:
> I have been reading this post and hopping for a small example. Can someone
> explain if I have a C[++] thread that fires an event to Lua how it can
> "hook-up" in a thread safe way to the event?

I remember having to deal with this self-same issue with SciTE
extensions. The issue is often that the actual event happens in
another thread, but must be raised in the main GUI thread. In that
case, I had a worker thread that read output from a process, which
then posted a message to a little hidden window, which could then
raise the event safely; there is an equivalent GTK mechanism.

I can post the SciTE extension code if anyone is interested.

steve d.