[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 16:48:16 -0500
On Thursday 26 January 2006 4:19 pm, Jon Smirl wrote:
> > implement read()=EAGAIN, call out to a registered callback if present,
> > epoll_wait(), get event, return.
>
> Note that if the filesystem doesn't implement O_NONBLOCK you simply
> won't get the EAGAIN return from the read call. If you code assuming
> O_NONBLOCK is implemented the same code will work if it is not.
right, the low level facilities are in place. but, since most of the unix
culture is "let it block, fork if you need to multitask", most high level
libraries expose only the blocking behavior.
the challenging part isn't writing the libraries, it's designing good
conventions that would let us join IO from several libraries and tie them all
with a single select()/poll()/callback, whatever.
a small proposal: writing a thin C library that wraps FILE* or fd- like
objects in a userdata and provides a few generic Lua functions: select(),
poll(), event(), callback(), or something like that. not the opening,
data-handling, closing, etc, funcitons, but the blocking,events,callback kind
of things.
then, any IO Lua library could use this C library to create this objects and
let them all be multiplexed together. right now, the file library and the
LuaSocket library don't know of each other, select() is in LuaSocket, LuaSQL
does only blocking IO, and so on.
let's write the scaffolding!
> lua should definitely provide a run-time implementation of sendfile()
no, that should definitely be in a library, not the language.
--
Javier
Attachment:
pgpUvGFy9hHM_.pgp
Description: PGP signature