lua-users home
lua-l archive

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

On Thursday 26 January 2006 7:12 pm, Diego Nehab wrote:
> The tough part is not to get these things to work, or even to make them
> efficient. The problem is to come up with a simple, consistent and
> portable interface that will make most people happy.

ok, what about something like this:

a C library that makes it easy to run a C function in a background thread. 
this background function wouldn't be allowed to use the lualib API, so it 
can't mess up with the Lua state.  each background thread is associated with 
a userdata object with the thread's state, allowing the Lua code to check 
when it's done.  besides, when the background function finishes, it's 
associated object goes into a queue, so it's easy to just ask for the next 
finished process.

so, if i want to write a new library and i want it to be nonblocking, i just 
write the Lua-callable functions to prepare and spawn these background 
processes.  inside them, it makes blocking calls, but it doesn't matter.

the resultant Lua API have non-blocking calls and a centralized 'finished' 

the key point is that the background C functions (part of the IO library, not 
the thread library) MUST NOT use the lualib API.  what do you think Diego, 
would that be doable without messing with the Lua core?  (the main downside 
of LuaThreads)

> The next version of LuaSocket will probably support IOCP on Windows.  If
> it does, it will be in association with a built-in coroutine dispatcher,
> similar to the one in Copas. I will avoid using threading as much as
> possible.

maybe if the threading done once... it could be done well enough

> It is unlikely that I will rewrite Lua's standard IO library to work
> with the same dispatcher. But I promise to think about it.  I will be

if we come up with an easy to use C framework, i volunteer to write file IO. 
in fact, it would be almost trivial, and probably the first test of the 

> bothering Mike Pall and David Burgess a lot with this subject in a
> couple months.

lets shake the table a little...


Attachment: pgp9Cbp_D9OsG.pgp
Description: PGP signature