lua-users home
lua-l archive

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


> -----Original Message-----
> From: lua-l-bounces@lists.lua.org [mailto:lua-l-bounces@lists.lua.org]
> On Behalf Of steve donovan
> Sent: woensdag 28 maart 2012 9:10
> To: Lua mailing list
> Subject: Re: Options for Asynchronous Callbacks
> 
> On Tue, Mar 27, 2012 at 5:40 PM, steve donovan
> <steve.j.donovan@gmail.com> wrote:
> > Multithreading is hard, as Barbie the Software Engineer says ....
> 
> So a wise engineer avoids it .. I have restored sanity by abandoning
> the 'async' part and only allowing callbacks to happen if either we're
> sleeping or waiting for processes to finish.  This is not too
> restrictive - one can always do everything in callbacks, remembering
> not to hog the thread and doing heavy stuff in background processes -
> which is very much the luvit philosophy, except in a 45K DLL that can
> be used by regular Lua.
> 
> This can still play nice with GUI applications since then winapi
> dispatches callbacks to a message window and calls them on the main
> GUI thread. (and GUI applications are all about callbacks)
> 
> But playing nice with something like LuaSocket is hard, for the
> reasons Thijs mentions - you have to get everyone to respect your
> locks. The temptation is then to make a lockable version of the basic
> LuaSocket TCP/IP core and still be able to reuse the rest of its
> machinery. You then get Copas-like functionality without the
> quick-timeout hacks.
> 
> Portability? Well, this was always intended as a Windows library; true
> portability is anyway hard because even when Windows looks like POSIX,
> it's doing it differently - for instance, you can actually throw a C++
> exception from a signal handler.  Besides, Windows doesn't always get
> the developer love it needs ;)> 
> steve d.

I Agree on the windows love...

The problem is that even though I like cooperative over pre-emptive
multitasking, my Lua apps live in a pre-emptive world, so I need to handle
this one way or another. And I think it could work but if modifying all the
standard libs like LuaSocket would be done for every project again/specific
(current state of affairs), or it would be a one-man-show, then it's not
feasible.
But maybe a generic interface can be added to the Lua core that facilitates
that, similar to the lua_lock and lua_unlock macros currently. Mainly
because this specific threading usecase it the one popping up over and over
again, without a satisfactory solution.

Suppose 2 functions are added;
Lua_RegisterThreadHandler()  --> register functions for lock/unlock of the
Lua state, by thread queue lib
Lua_GetThreadHandler()       --> collect lock/unlock functions to be used by
any library that might block
The initial lock/unlock functions set would be stubs, returning null for the
lock/unlock functions

This would imply no impact on the Lua core performance as they are simply
not used.
Provide an extra version of the IO lib that, when loaded replaces the
original IO lib with one that does call the lock/unlock functions.

If the developer does not use a threadqueue lib, all stays the same, once a
developer loads a threadqueue lib that registers itself as the ThreadHandler
and provides the lock/unlock functions, it enables the callbacks to be
collected using a poll method or by having them enter on their own os thread
(see my previous post). This can be easily added to existing coroutine
schedulers/dispatchers.

If the Lua core facilitates such an API, then lib developers will surely
follow because it's a standardized API and no longer project specific.
Not a solution for today, but will benefit future use. Also, because its
more coroutine like and less pre-emptive like, I think it is a more Luaesqe
solution than the current lua_lock/lua_unlock macros.

Thijs

PS. Additional benefit; this can be loaded at runtime instead of the current
macros that have to be set at compile time.