Boost logo

Boost :

From: mfdylan (dylan_at_[hidden])
Date: 2002-02-24 20:52:39

--- In boost_at_y..., "davlet_panech" <davlet_panech_at_y...> wrote:
> --- In boost_at_y..., "Timothy M. Shead" <tshead_at_k...> wrote:
> > On Sun, 2002-02-24 at 16:03, davlet_panech wrote:
> Perhaps; although framing is not an issue for stream-based
> Blocking doesn't seem like a big issue for a stream also -- after
> file streams are blocking, even though the underlying OS frequently
> supports non-blocking file operations. I think I agree that error
> handling might be problematic, though.
There is a reasonable difference between blocking sockets and
blocking files though, in that files access is usually at worst over
a slow LAN, whereas socket access is frequently over an unreliable
WAN with potential 10-20 second blocking times. OS's can also do a
lot of caching for files that can't be done with sockets.
If you can get away with one thread per socket, then blocking is fine
of course, but in my own experience you need somewhat more
sophisticated mechansism whereby a block allows some background
processing to go on (which might include accepting more connections
or processing data on other existing connections).
Error handling almost has to be done with exceptions - and note that
basically all socket errors except EWOULDBLOCK mean the socket is no
longer usuable anyway.
Still given all this, streaming over a socket is quite workable. I
put a socketbuf in files sometime ago and also a binary_stream (the
two are actually orthogonal, but people seem to assume socket I/O is
usually binary whereas file I/O is usually ascii).


Boost list run by bdawes at, gregod at, cpdaniel at, john at