Kacheong Poon writes: > James Carlson wrote: > > The point was that applications often have many different kinds of > > file descriptors (including, say, a few TCP _listen_ sockets that > > aren't receiving data at all, and some pipes connecting other > > processes), and are often designed with one big polling loop for *all* > > of the file descriptors. > > > The question is if these kinds of apps really need to > use the new call for performance reason?
So, you're targeting only applications that have lots of sockets but don't listen for new TCP connections? Which ones are those? > > If you design an interface that only works with one kind of file > > descriptor, but not with the others, then application writers are > > forced to segregate the descriptors into different 'kinds' for the > > main loop. That may not be very easy to do, depending on the design > > of the application, and given the way file descriptors are mostly > > fungible under UNIX, it'd be an odd problem to deal with. > > > Note that select() still works for all file descriptors. Yes, but I _thought_ it was clear that you wanted to get rid of select/poll in the path of the I/O, on the grounds that it results in too many system calls. Right? > Let's say with the above app, one of the file descriptors > in the select() set is a UDP socket. And the app needs to > know where the received datagram comes from. So the app > needs to use recvfrom(). Are you saying that the fact that > recvfrom() is used but not read() (which can be used to > receive from other file descriptors, say a character device) > is incorrect? How about the need to receive ancillary data > from a TCP socket? No, I'm not saying any of those are wrong. I'm saying that an interface that accepts multiple file descriptors in an attempt to avoid poll-and-figure-out-which-one behavior, but that handles only one kind of transaction (I/O) and only one kind of descriptor (a socket) might be too limited to use easily. What's the intended usage model? -- 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 networking-discuss@opensolaris.org
