[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Coroutines and blocking IO
- From: Javier Guerra <javier@...>
- Date: Thu, 26 Jan 2006 23:58:58 -0500
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'
queue.
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
framework
> bothering Mike Pall and David Burgess a lot with this subject in a
> couple months.
lets shake the table a little...
--
Javier
Attachment:
pgpCigjo_Xfjm.pgp
Description: PGP signature