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:
pgphm9PP7SGPz.pgp
Description: PGP signature