In article <d106fh$uj2$1@sea.gmane.org>, Jonathan Biggar <jon@levanta.com> 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.) meeroh