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