"Matt Liotta" <[EMAIL PROTECTED]> writes: > We were talking about scalable in the context of current number of > sockets. Real-time signals allow for significantly more current sockets > than any other architecture. > > -Matt
I think this oversimplifies things. There are two important counts of sockets: total sockets and active sockets. Which (or what else) did you mean by "current sockets"? Scaling up the total number of sockets is usually done by adding or removing sockets one or a few at a time -- /dev/poll, kqueue() and real-time signals all do this. select() and poll() require the app list all sockets for each system call. Scaling up the number of active sockets is done by reporting only active sockets instead of status for all the sockets. Again, select() and poll() do this poorly; /dev/poll, kqueue() and signals do it better. If each active socket only requires a little bit of user-space work (e.g. HTTP or IRC), delivering a signal for each one adds a lot of overhead. Delivering activity notices in groups reduces this overhead, and so allows sockets to be active more often. The cost is that the app may end up waiting longer before it learns of activity for a given socket. -- Michael _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
