Carlo Wood <carlo <at> alinoe.com> writes:
2. It is unavoidable that this library uses threads.
On some platforms, you are almost certainly right - as an implementation detail. But I don't agree that threading needs to have anything in particular to do with the IO multiplexing lib.
There are two main reasons that I see:
1) On windows we have a limitation of at most 64 'Event' objects that can be 'waited' for at a time. This is not enough for large server applications that might need thousands of TCP/IP sockets.
Ok.
2) On windows there are different types of handles/events. It seems to make a lot more sense to use different threads to wait for different types. For example, there is a WSAWaitForMultipleObjects (for sockets) and a WaitForMultipleObjects that allows one to wait for arbitrary events (but not socket events(?)). More in general however - there seems to be a need to use different ways to demultiplex and handle different types - even if the handles of all different types are the same (ie, 'int' on UNIX).
UNIX is a mess given various combinations of SysV IPC, posix, aio that works for disk and not much else (ymmv) etc with various extensions and implementation "details". I'm not sure that trying to support them all is the right direction. Can't we define some set of waitable objects/interfaces that can be implemented on top of whatever platform facilities work best (with a fallback/initial impl that uses whatever works at all on a reasonably basic platform)? This might do away with the "need" for threads (which are yet another source for incompatibility anyway) at some cost in flexibility.
Consider the major difference between a listen socket, a very busy UDP socket and a very busy memory mapped filedescriptor. It might be easier to regular priority issues between the different types by putting their dispatchers in separate threads.
Maybe (probably not for select, but perhaps for kqueue, epoll)? But why does this need to be reflected in the design beyond allowing (not requiring) many threads each with its own event dispatcher?
Note however that I DO think that the callback functions for each event (that is, the moment we start calling IOstream functions) should happen in the same thread again; this new library should shield the use of threads for the user as much as possible!
You propose that threads may be needed as an impl detail that should be hidden. I agree - but I don't see how that is any different from suggesting any other platform dependent implementation detail - eg. futex's and epoll should/might be used on linux. Hopefully, the interface doesn't change. I think you are saying you want an interface that allows the priority of a waitable object to be specified in some way, but that they get delivered in priority order to a single thread? So a minimal approach would be a single event receiver thread waiting on a non-prioritised system event interface, placing events into a priority queue for delivery to the "main" thread? That sounds like a reasonably portable approach, and one that can with little effort support multiple event receivers to address other issues you raise, but I don't think it should be visible at all to the user, or required by the design. I can also imagine cases where the overhead of such an approach would be excessive, and it would be preferable to use a more limited dispatcher with less overhead (or to use multiple such dispatchers, each operating independently, in their own thread, and leaving any synchronisation issues between these threads up to the user. Oh - you say it makes no sense to agree with higher numbered issues. I'm not sure why - this threads issue seems orthogonal to all the rest? Or are you saying that your impl. of 3+ relies on threads? Regards Darryl.