[boost] Re: [network] An RFC posted to the sandbox

From: Bob Bell (belvis_at_[hidden])
Date: 2005-04-15 13:47:28

Don G <dongryphon <at> yahoo.com> writes:
> Hi Bob,
> >Caleb Epstein writes:
> >> As far as the appropriate subseconds type goes, we
> >> should probably pick the highest-possible resolution
> >> that makes sense, which I'd contend is probably
> >> microseconds. Some operating systems may be able to
> >> slice time (and signal events) at resolutions below
> >> milliseconds, but I doubt any can go deeper than
> >> microseconds.
> >
> > I wouldn't take that bet. I know Mac OS X can measure
> > time as finely as nanoseconds (but I have no idea how
> > many services, i.e. sockets, actually work at
> > nanosecond resolutions; it doesn't seem outside the
> > realm of possibility that, given the way technologies
> > advance, that within a few short years, microseconds
> > simply won't be fine enough. One of the nice things
> > about double-as-time-unit is that it avoids resolution
> > issues altogether.
> 
> With processor speed basically stalled out around 4GHz, it is at
> theoretically possible to measure time to about 0.25ns.

The end of Moore's law has been predicted for many years; I don't see
any reason to believe that processor speeds will stay stalled at 4GHz
for long.

> Not that a
> scheduler would muck about at that level.

Agreed.

> For timeout purposes
> (especially for networking), I think microsec is fine.

Also agreed.

> In particular,
> this is what select() wants. epoll_wait uses milliseconds. Windows
> generally uses milliseconds. The kqueue/kevent folks do want
> nanoseconds. The precision of the implementation is not clear (just
> it's interface).

And it's the interface we're discussing. I have no idea of the
implementation uses nanosecond precision, but I don't think that
matters very much. What matters is an interface that lets users
succinctly communicate their intentions.

> Having said that, I like Caleb's proposal to offer multiple ctors for
> timeout purposes as long as they don't get ambiguous. That way,
> floating point can be used as well as pure integer (if that kind of
> thing still matters to anyone<g>).

I'd rather approach it the other way around. Instead of saying,
"Let's provide various constructors in case someone wants them",
we should say "Let's provide a constructor if we know there is a
demonstrated, reasonable need for it." Is there a reasonable need for
mutliple constructors which allow a user to specify time values in
multiple ways?

As for ambiguity, there's ambiguity to the compiler, which can
probably be worked around, and then there's ambiguity to a human,
which can be much more difficult to deal with. In another post, I
wrote as an example:

   timeout  t(100);

Is this 100 seconds? 100 milliseconds? 100 microseconds? With a
single constructor using a type like double with a very simple
meaning (i.e., seconds), there is no reader ambiguity, and the
interface becomes very simple. At the same time, implementing it
(converting to the underlying platform representation) is trivial.
If it were me, I'd think long and hard about whether any other
constructors are really necessary.

Anyway, like I also said in that other post, I don't have strong
opinions about the network library -- I'm far from an expert on
networking. I do have opinions about library and interface design,
however, which is what motivated my comments in the first place.
But my hat's off to anyone who would undertake the effort to produce
a cross-platform networking library; since I won't be involved, take
what I say with a grain of salt, and do what you think is best.

Bob