lua-users home
lua-l archive

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


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