[boost] Re: Network library: What we have until now

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-14 21:13:11

Hi Iain,

On Thu, 2005-04-14 at 06:43 -0700, Don G wrote:
> Hi Iain,
> 
>>> Not all platforms have threads. There may even be
>>> some that don't supply co-operative multi-tasking.
>> 
>> I'm sure they exist. Can we name any that are
>> important to this design?
>
> I don't know which specifically but it will probably
> be the RTOS'es such as PSOS, VxWorks, maybe QNX, and
> Symbian plus maybe others.

You mean an RTOS doesn't support threads? ;) Seriously, though, would
someone with network experience on these systems care to speak up...?

>> At issue here, for me<g>, is that the grouping of
>> objects to select/whatever calls is non-portable.
>> In other words, the select_set class must do many
>> silly things on some platforms to support a bad
>> mixture or too many. So, in my proposal, this is
>> in the realm of internals.
>
> Platform select may not be completely portable but
> the concept is supported across most if not all
> platforms that I am aware of. Therefore, it is not
> hard to abstract a standard set of behaviour for
> C++ and leave the Lib implementation to deal with
> the differences. Ace call the the Reactor.

This approach still leaves the user with the manual bookkeeping to
perform, and I'm not seeing why. Is it just to avoid threads?

>>> BTW callbacks are just *one* way that async
>>> completion can be reported.
>>
>> Agreed. But don't we have to pick something? ;)
>
> Why? aio supports polling, callbacks, and signals.
> Different users have differing needs and a good Lib
> will support the different patterns.

So you agree - we have to pick something. ;) Your something sounds
like multiple techniques, but it is still something that must be
chosen. In my proposal there is: blocking, async w/callback,
non-blocking w/callback, and polling (via non-blocking w/o callback).
Signals are platform-specific (and scary<g>), so I didn't include
them.

For sake of discussion, let's just say we support 5 different
methods. It sounds like an SSL implementation of a net::stream would
have to support them all as well? What about higher level libraries?
Following this reasoning, it would seem that all levels of networking
must support all styles of completion detection/notification.

Perhaps this straw man is inaccurate, but if it is accurate (and I
think that it is), I can see why Boost has no net library. And even
if it did, who in their right mind would want to write layers on
top<g>? It would be way too complex.

My philosophy on this is simple (if indeed anything in this space can
carry that moniker<g>): what is the problem? I think it is achieving
concurrent operations with portable/safe/efficient notification of
completion. I think a small number of operation modes (see my
proposal) is more than adequate to achieve this end. The fewer modes,
IMHO, the better.

If threads or their facsimile are not portable enough, I think some
minor adjustments to my proposal might work. I would like to hear
from someone familiar with a system that has nothing remotely like
threads before carrying out this particular thought exercise. ;)

Best,
Don

                
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/