James Carlson wrote:
> 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.
The question is if these kinds of apps really need to
use the new call for performance reason?
> 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.
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?
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
