Jeremy Harris writes: > > Can you clarify? > > The design was for an interface. It didn't constrain implementations > to the extent that kernel involvement was not possible. Indeed, since > interaction with non-async use of sockets was considered (i.e. these > objects called sockets are still really sockets), I'd have thought > kernel involvement a requirement for a decently-performing > implementation.
Yes, of course there'd be "kernel involvement" if you had an implementation of async I/O. The original topic of discussion, though, was the implementation of a kernel interface to sockets. > I'm unsure what you mean by describing it as a "user space design"? It works in user space. :-/ The kernel is different, and has different issues, such as dealing with interrupt threads and (potentially) different memory spaces; and that's leaving aside all the smaller issues about programming interface differences for memory allocation, mutexes and the like. The issues are many and subtle. For instance, in user space, close(2) is Async-Signal-Safe. There aren't any "signal handlers" in the kernel, and if there were any, close(2) likely wouldn't be one of them, because the idea of having the close operation continue "in the kernel" (as it normally does when invoked from user space) is alien. I don't see how a specification intended for user space is the right answer here. It might possibly be some sort of starting put, but it necessarily will be incomplete. > However, it sounds like Sun hasn't produced an implementation, so > in that sense it's no answer to the original poster's query. Yes. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 _______________________________________________ networking-discuss mailing list [email protected]
