Bart Smaalders wrote:
> Kacheong's design involves either a call to port_getn or a call to
> select/poll., followed by a call to his new function, recvfrom_list():
A correction, Stephen Uhler proposed this.
> while (1) {
> select(...) /* get list of active sockets */
> recvfrom_list();
> process_all_data();
> }
>
> This technique will retrieve 1 available message on each socket
> at the cost of 2 system calls.
This is the same number as without this call. The
benefit of the call is that if multiple sockets are
ready, we are saving those extra recvfrom() system
calls. And this is true for certain types of traffic.
> If the traffic is not evenly
> distributed, more system calls are required, to the point where
> 2 system calls are required per message if all the traffic
> arrives on a single socket.
The same as today's apps. A "work around" for this
is that the list can contain more than one rd_list for
the same socket. If there is only one message available,
only one of them will be filled in.
> This suffers from the following limitations:
>
> * As noted above, it doesn't handle asymmetric loadings well
> * Does not easily admit the use of threads; only one thread
> can meaningfully poll on a set of fds at a time.
I guess this is not true if event port is used. But
using event port may mean that existing apps need to be
modified extensively.
...
> The downsides w/ asynchronous I/O is that some thought needs to be
> given to transmit/receive buffer management, and that it may
> represent a new programming pattern for networking developers.
This is the main reason for the simple recvfrom_list()
call. While it has many short comings, the benefit of
it for some types of network app is great.
--
K. Poon.
[EMAIL PROTECTED]
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
