[boost] Re: [network] An RFC - updated

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-24 17:48:12

Hi Michel,

> Are you agreeing that we should have a level 0
> close to the socket api supporting a portable
> subset or are you giving in to pressure ;).

Even my proposal used sockets internally, so yes, there should be a
layer that minimally encapsulates them and does some smoothing of
irregularities (in particular EAGAIN vs. EWOULDBLOCK). I just don't
think that is the right layer to do any high level work.

> I can see the troubles you are afraid of. But
> having weak_refernces in the registry would get
> the objects destroyed as soon as there is no
> strong references to it, so if you have
> destroyed all objects associated with a network
> you should be home free. But I guess some nasty
> circual references or whatever could keep the
> object alive.

This might solve the problem, but would produce thrashing if you
transition from 1-to-0 a lot.

> Btw, arent you using shared ptr for the network
> object

Yes (or its equivalent)

> so essentially you have the same problem today?

No. The owners of the network object are ultimately part of an object
hierarchy. The root object takes everything out with it.

> It would be quite easy to write a function that
> maps uris to our address notation. And usually
> you provide some kind of gui which handles this.

Agreed. But it would also be "easy" to do what I propose ;) This is
an issue that I would still like to ponder, but I don't believe it
belongs below the app. Perhaps a library could implement this and be
reusable, but the mechanism I propose should probably not be thinking
this way. It seems to complicate object layering and things like
that. At least to me.

> I think probalbly what you want to do, is to use
> the same protocol implementation over several
> different transports ie tcp/named pipes/serial
> or whatever and it's here the address and factory
> comes to play.

Indeed. :)

> I think as I have expressed before if you actually
> know the type you should be able to use concrete
> classes directly such as tcp_stream/accpetor/
> connector since they could expose more
> functionality than the generic net_stream.

But the need to do so is not there. Things flow immediately into
generic code once the text has been converted to address object.
Again, if there is some TCP-specific stuff (eg: nagel), it can be in
the abstract interface. If the user needs to know if something is
supported or not and wants to take different actions depending, that
is somewhat different. But again, I would like this to be part of the
abstraction so that we don't effectively throw away its benefits. A
consistent focus on abstracting behavior seems (to me) a better
approach.

> Ok I think I need some more explaining in these
> concepts and some better names than nexus and
> channel.

A very close analogy would be channel=HWND, nexus=GetMessage_loop.

> But basically you have an event_sink (channel)
> and a event_source(nexus)

Not exactly. The nexus (bad name, I know) is the queue, not the
source.

> that posts completions to the sink. And if the
> event_sink goes out of scope notifications is'nt
> delivered.

Yes.

> I have implemented this with having synchrounous/
> blocking close and deletion that would deque and
> completion whit a error stating the operation has
> been cancelled. But agreed it sometimes can be
> tricky to get this right and don't get spurious
> completions after deletion.

Oh yes: tricky! ;) The general async library I must obviously propose
soon<g> solves this with the concept of a channel. It is the proxy by
which one answers the "are you still there?" question. The channel is
connected to a queue (a "nexus") and that is the queue to which it
will post boost::function<> objects in channel::async_call. This call
is thread-safe.

The channel user is decoupled from the entity that services the
queue, which I also feel is very important to this solution. Anyway,
without going any deeper (yet), I hope that clarifies things.

> Unfortunately computers are discrete and bounded
> machines with limits on the resources at all levels,
> but we do our best to hide these limits from the
> programmer and user so he can sail away and believe
> there is infinite memory and sockets available,
> dont' we ;).

Yes, indeed. This sub-thread of the discussion was really an
exploration of how to appease those that insist on the possibility of
a single-threaded implementation (not just interface). I have no need
for such an implementation, but am willing to explore the possibility
as long as it doesn't sacrifice the larger objective of abstraction.

Best regards,
Don

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com