Kacheong Poon writes: > I am not too sure for the above apps, this new call's > benefit is really huge. It is true that it can also reduce > the number of system calls for the above apps. But I doubt > that the effect is significant. Using Stephen's example, > the call is very useful as the app has many sockets and > each socket is getting a packet every 20ms. I doubt that > for character devices, disk I/O, ... this kind of work > load is typical.
I agree that character devices likely don't have this kind of performance requirement. That wasn't the point. 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. 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. -- 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
