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

From: Don G (dongryphon_at_[hidden])
Date: 2005-04-16 00:00:37

Hi Iain,

>> I knew we had a definition problem: handling
>> 1000+ simultaneous connections would not be
>> something I would label as "simple"! ;)
>
> With all due respect I think that you are
> confusing size/scalability with complexity.

I was just being complimentary, not confused. That was the day
before... :)
 
> Rather than 'guess' what a boost::function costs
> why not look it up here
> http://www.boost.org/doc/html/function/misc.html#id538868

Time and priority. I didn't think it would be an issue and thanks to
the link you provided, I am more confident of this.

>>> I hope this won't happen. There are several I/O
>>> patterns in use out there.
>>
>> But, honestly, how many do we need?
>
> *All* of the ones provided by the 'C' socket API
> i.e. single threaded reactive ( blocking), Single
> threaded reactive ( non-blocking ), signal driven,
> multi-threaded async, and multi-threaded reactive.

But why stop there? How about posting to HWND's, kernel event object
or IOCP as Winsock does? Hyperbole aside, the proposal I posted has
no signals explicitly (though, with some thought perhaps they could
be used internally) and does some hand waving about single-threaded
reactive using function queues instead of manual bookkeeping. The
others are supported. (though I may not be following your distinction
between MT async vs. MT reactive).

> And before you say again that signals are not
> portable, they have been part of the libc library
> on DOS and windows from MSDOS 3.0 on Lattice C,
> Borland Turbo C 2.0 and MS C compilers and it is
> still supported under Windows XP.

Oh, those where they days :)

But, I think you ended your search a bit early. Look for any of these
in MSDN (SIGIO, SIGPOLL, O_ASYNC, F_SETSIG, fcntl, sigaction,
siginfo) and you will only find them in the Unix Code Migration Guide
and no hits for sigwait or sigwaitinfo. Oops, "fcntl.h" is a C RTL
header, so you will find those hits, but the top 2 are the UCMG.

What I know of the support for signal on Windows is that you can set
a handler (via signal) and call it yourself (via raise). Nowhere have
I seen a hint that Winsock will ever raise a signal. The issue, I
think, is that while libc may support a primitive form of signals,
Windows itself knows nothing about them. There are few "signals" that
are sent to console applications (some in spawned threads), but that
is it AFAIK.

>> I can only think of one advantage of multiple styles:
>> familiarity with existing practice.
>
> Then I'm afraid your education has been some what lacking.

[ad hominem ad nausem]

> Threading is greate for certain kinds of high performance
> servers but can introduce a lot of complexity. ( potential
> for deadlocks, races, priority inversion, starvation etc)

Agreed: threads are a (sharp) double-edged sword. Queues of functions
can greatly simplify this situation, however. I have written plenty
of single threaded async code (using the multithreaded network
library) in this way and not suffered any of the problems typically
associated with being multithreaded. I also knew that I was trading
some performance for that luxury. If it ever becomes necessary to
measure this performance loss, I may have more to say on this. :)

> Single threaded fork/exec reactive servers eliminate the
> complexity of threads but add complexity if they need to
> share data ( IPC ) and use heavy weight context switches.
>
> Both of the above, because of context switching behave
> non-deterministically with regard to time. Which is why
> you have signal driven I/O.
>
> We do not chose our architecture based on familiarity
> but rather on the requirements and these models each
> satisfy different forces.

Even though it is my proposal, I sometimes find it difficult to keep
interface separate from implementation (based on a thread pool) in my
discussions on this topic. I chose to trade some user visible
techniques (signals and select-like groupings of objects) for safety,
simplicity and portability. Yet, signal-driven I/O may be a viable
implementation path for the interfaces I proposed.

I have little experience with the fine points there, but I don't see
any glaring reason it cannot be done. The biggest concern is
documenting what context(s) user callbacks are made. It matters to
the user and needs to be clearly spelled out. Also a set of rules
derived from the possible contexts needs to be articulated. I
endeavored to do so based partly on the interface, but also on the
particulars of the implementation I had in mind. Alternative
implementations will certainly flavor these topics.

Beyond all that, I suffer no delusions that the library I propose
will satisfy all needs of all applications. I do believe, however,
that the vast majority of applications needing networking facilities
do not need to be optimized to such a degree. Apache.org is not going
to drop everything and start using this (or any other) C++ library.

Within the scope of the design I proposed are many avenues to
increase performance. Some involve threads, but with well isolated
data per connection, perhaps no locks. Again, this is implied from my
implementation, and it is not clear that it should be part of the
interface (though it is a useful piece of knowledge<g>).

Best,
Don

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