[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: RES: package system modification (module loaders)
- From: skaller <skaller@...>
- Date: 20 Jan 2005 13:16:30 +1100
On Wed, 2005-01-19 at 22:55, duck wrote:
> > All the above. I had a look at recently posted LuaThreads package ..
> > but to build it required modifying the Lua sources (via a macro
> > if I recall).
>
> That's special to LuaThreads: the core needs to be recompiled with
> luathread.h #included throughout.
Unfortunately, this probably is not the case. Any library
providing either
(a) Access to system resources, or
(b) Access to fundamental programming extensions
both needs to be done in C and also needs to
intervene in the core. This leaves two kinds
of extensions that don't:
(c) algorithms+data structures done in Lua
(b) bindings to algorithmic C libraries done in C
A module/package system can handle loading (c) and (d),
but you need *build system* support for (a) and (b).
> The "rebuild" is, as Diego notes, a convincingly necessary core-tweak
> *specific to pre-emptive multithreading*.
That one is. I have examined another that does C++
exceptions instead of setjump/longjump. My version
of Lua is built with C++ and has to support
exceptions -- setjump/longjump is not acceptable.
(At all).
To do sockets, you basically have to have threads
to handle blocking/cancellation, and that intervenes
in the core too if you do it right (so coroutines never
block).
To do signals, you probably need to fiddle the core
as well -- running a lua script asynchronously is likely
to create havoc unless managed.
To run with a GUI, you will need to fiddle the core
too, since most GUI are badly designed crap which
have event loops that take over main control.
These issues aren't peculiar to Lua, the issue is
really how to handle these things in a simple way.
Unfortunately .. I'd say they account for a good
half of all extensions-- access to system resources
is one of the main reasons to have extensions.
Python already handles most (but not all) of these
things -- at the cost of a much larger core.
[Stackless operation is something it doesn' handle]
> LuaSocket, for instance, requires no such rebuild. It's a pure add-on lib
> in C and Lua.
And therefore probably doesn't work properly with threads
and coroutines.
> I've taken to statically including everything :-)
> LUALIB_API int luaopen_lstatic(lua_State *L) {
> /* Make things "5.1-style" */
> # include "compat-5.1.b2c"
> /* Expose initialisation functions for C libs later loaded via Lua */
> lua_register(L, "luaopen_lsocket", luaopen_lsocket);
> /* Do special preconfig, inc. package.loaded & package.preloaded */
> # include "lstatic.b2c"
> /* Load any Lua libraries we want statically bound */
> # include "socket.b2c"
> return 1;
> }
This looks like a good solution when it works.
--
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850,
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net
- References:
- package system modification (module loaders), Tiago Dionizio
- RES: package system modification (module loaders), André de Leiradella
- Re: RES: package system modification (module loaders), Adrián Pérez
- Re: RES: package system modification (module loaders), duck
- Re: RES: package system modification (module loaders), Tomas
- Re: RES: package system modification (module loaders), skaller
- Re: RES: package system modification (module loaders), duck
- Re: RES: package system modification (module loaders), skaller
- Re: RES: package system modification (module loaders), duck
- Re: RES: package system modification (module loaders), skaller
- Re: RES: package system modification (module loaders), duck