Miro Jurisic wrote:
The key functionality of a sockets library will be the dispatch mechanism. Something that streamlines how blocking/non-blocking mode interacts with select/poll/devpoll/windows events and a threaded vs reactive model will be highly valuable. Particularly if library allows the choices to be changed without affecting much/any of the code.
That's true, I don't think this is in any significant way particular to sockets; the same holds of any other interface that can have high latency -- e.g., stream I/O or filesystem operations. So, I agree this is an interesting question, but I think it should be solved outside of the sockets library and then a sockets library could build on top of that (as could other libraries).
(I am not saying that I know what that solution would be, nor that such a solution doesn't already exist in the form of threads and signals; I haven't thought about it in that much depth, but I don't think that what you are asking for is entirely specific to sockets, either.)
I agree 100%. People who do socket programming have the first and most obvious need for a good dispatch library, but it certainly can be useful for other things. I'd like to see something that is sufficiently abstracted so that anything that can be "waited" on or generates events can be plugged into the dispatch system, not just file descriptors. -- Jonathan Biggar jon@levanta.com