[lkml]   [2005]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectselect() efficiency
Please forgive and redirect me if this is not the right place to ask 
this question:

I'm looking to write a sort of messaging system that would take input
from any number of entities that "register" with it.. it would then
route the messages to outputs and so forth..

I'm guessing that the messaging system would be a single process on the

So, I'm considering making the means of input to the system be a unix
socket. An entity would connect to the socket as it's means of
inputting messages into the system.

However, lets suppose that 1000+ entities connect to that socket.. this
would require the message system's loop to be adding 1000+ file
descriptures to an fd_set and call select() every time it loops around
to check for any messages.

So, my question is: how efficient would things be, doing selects() very
often on 1000+ file descriptors? I'm not aware of max size for an
fd_set.. (I do know that NT is limited to 64 handles.. but that's really
beside the point unless I look at porting someday)

Should I go another route?

The system is meant to rapidly route messages ASAP.. so it would be a
bad idea to say write them to a file and poll the file or something like

Another thought was to use a system-wide mutex and write to a named
pipe, but the socket method seems more appealing to me in design... and
I didn't know if it was pretty much equivalent either way since either I
will do the work of dealing with 1000+ things or the kernel will.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-07-22 23:25    [W:0.056 / U:2.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site