[boost] Re: Sockets: proposal for a library design

From: Jonathan Biggar (jon_at_[hidden])
Date: 2005-03-13 13:48:09

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_at_[hidden]