James Carlson wrote:
> 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.
Sure.
> 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?"
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. And for those apps which need to deal
with this kind of network work load and at the same time
needs to deal with character devices, I suspect that having
another thread handling the other file descriptor types is
better.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
