Messages in this thread | | | Subject | Re: > 15,000 Simultaneous Connections | Date | Wed, 08 Sep 1999 00:57:13 -0700 | From | Jason Nordwick <> |
| |
>One of the major drawbacks (besides the scalability issues discussed >here) of >select is the missing integration of other kernel generated events. It >would be >really nice if the select replacement could synchronously wait for >signals and >maybe SYSV-IPC. If it could wait for signals the libc implementation >might be able >to wait for pthread conditions, too. >What I want to say is, that I want to be able to wait for just about any >event. >This way single threaded applications would be much easier to write. >
Having done some (but admitedly, not very much) win32 programming with a similar event interface, I have mixed feelings about this. For this you get a unified interface and the ability to have a single thread wait for conditions of various types. The unified interface does make it more difficult to determine what is happening locally (just look at a win32 code segment and see a WaitForMultipleEvents() call and try to trace you way around to see what events are being passed around). Waiting for different types of unrelated conditions does mean you can get away with more single processing, but is usually not that useful, since many times these events are being generated by other threads, so you kinda defeat the purpose. So it is usually done better with multiple threads waiting seperately.
What you also make more difficult is extending the semantics of the call without burdening many people who don't really care about the changes. For I/O you just want to wait for anything to come in, but for thread termination you may either want to wait for a single thread to terminate or all of the threads you are interested to terminate. This added complexity is useless in the I/O cases and should not impact it. Also, event arguments become more complex. You either have the event struct be a union of various types (ugh) or you have a descriptor and wait event flags in which case you destroy some of the ability to type check the call (especially since both file descriptors and thread ids tends to start at 1 and increment).
>This would mean a change to declare_interest so that it can accept >parameters >other than a file descriptor and to the event_descr_t so that it can >report >events other than those related to a file descriptor. > >Regards > Joerg >
I may be biased since I think that select() is fine and efficiently implementable. It is also very simple, which is good. A general purpose event call will never be able to work for *all* events well (if you have user fired events, too, then this would never be possible), so I think that seperate event queues make more sense, are easier to implement efficiently, and are easier on the user in the long run.
-jason
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |