James Carlson wrote: > Bart Smaalders writes: >> Kacheong Poon wrote: >> Define a new asynchronous call similar to lio_listio that permits >> the collection of struct sockaddr & socklen_t info. This would >> then generate async io completion events, which could be retrieved >> via an event port once the IO had completed. > > This seems reasonable to me, but I think the error semantics have to > be worked out _very_ carefully. The sendfile/sendfilev fiasco gives a > pretty good cautionary tale. > > As for making it sockets-only, I'd be worried that application > programmers would be sufficiently constrained that they would end up > being unable to use the resulting interface. Every time we've tried > to come up with one of these special new interfaces, the first > question asked is, "great, but my polling loop code is currently > pretty generic, so how do I get <STREAMS, character devices, other > I/O> into this interface?" >
We already can do async IO to regular files, pipes, raw disks, etc using the existing async io routines. The *msg, etc, calls need additional passed in/returned information (sender address & length) so the async IO calls to initiate such IO requests need to be different, and if we want kernel level parallelism sockfs needs modifications. However, there's nothing stopping one from writing a single loop that issues disk & udp network IO requests, and handles the resulting events, just as a single event port loop can handle async IO requests, timer completion events, etc, today. For connected sockets (tcp or udp) there doesn't appear to be any reason that the existing routines cannot be used. Right now we have no async IO support in sockfs, so libaio (now in libc actually, thanks raf) emulates true async IO w/ user-level threads behind your back. I agree that, as usual, the error semantics are critical. - Bart -- Bart Smaalders Solaris Kernel Performance [EMAIL PROTECTED] http://blogs.sun.com/barts _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
