>>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I've been pretty much assuming we'd need:
DS> open
DS> close
DS> seek
DS> tell
DS> push_filter
DS> pop_filter
DS> read
DS> unread
DS> write
DS> prefetch
DS> and maybe have the return data have some 'I/O complete' marker so
DS> async I/O will work out properly.
hmm, i have an itch that says we will need more vtable support for async
i/o but i can't put a finger in it yet. how are callbacks handled? what
about private data to each asynch request (typically this has the
object/sub to callback and the handle info. possibly it includes data
passed in from the user code)? what about straight timers or i/o
timeouts? would they have a different call or just optional params on
read/write?
i always included socket connections and accepts in my event loops. do
they belong here at this level? or is that integrating it too tightly?
is the open super smart (i proposed something like that in an rfc) which
can handle socket connections? with an attribute based api, it can be
made to do that but do we want attribute parsing at this low level? i
would think these are c calls and positional params rule the day.
'nuff musing for now.
uri
--
Uri Guttman --------- [EMAIL PROTECTED] ---------- http://www.sysarch.com
SYStems ARCHitecture, Software Engineering, Perl, Internet, UNIX Consulting
The Perl Books Page ----------- http://www.sysarch.com/cgi-bin/perl_books
The Best Search Engine on the Net ---------- http://www.northernlight.com
