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

From: Iain Hanson (Iain.Hanson_at_[hidden])
Date: 2005-04-15 10:21:01

On Fri, 2005-04-15 at 06:32 -0700, Don G wrote:
> Hi Maxim,
[snip]

> > One of my previous project was a soft realtime VoIP
> > softswitch. It has only one thread of execution and is
> > capable of handling 1000+ simultaneous calls (2000-
> > 4000 sockets). It scales up by just starting additional
> > processes on the same box, no recompilation needed, no
> > locking, simple and immensely powerful.
> 
> 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. They are not the same thing. An application gateway is
often a very simple piece of software irrespective of the number of
connections it handles.

> 
> I have multiple thoughts here. First, I think the only difference our
> two approaches would yield is that with my approach, one might need
> locks. I did say "might". No lock is needed if the object managing a
> connection is basically autonomous, changing only its state is
> response to I/O completion or requesting further I/O, and/or creating
> new connections. While the internals of the network implementation
> are threaded, on a per-connection basis, callbacks are single
> threaded.
> Secondly, I don't think a queue of boost::function<> would be found
> by the profiler as a performance bottle-neck (though I haven't looked
> inside it at all). This is the approach I have taken to handle lots
> of async calls from one thread. Not 1000+, but I'm not sure the
> hardware and OS you used.

Rather than 'guess' what a boost::function costs why not look it up here
http://www.boost.org/doc/html/function/misc.html#id538868

> 
> >>> 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.

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. see http://msdn.microsoft.com/library/default.asp?
url=/library/en-us/vclib/html/_crt_signal.asp

> >
> > This is the main questions. I doubt we can ever
> > answer this. So, I see no reason in dictating a
> > style.
> 
> There are some reasons for picking a small number of styles:
> 
> 1. Simpler for a user to understand
> 2. Simpler to document
> 3. Simpler to test
> 4. Simpler to write higher level libs (they should have
>    have symmetric styles for their users)
> 5. Not all styles are portable (w/o undue complexity)
> 6. Simpler to implement :)
> 
> 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. 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)

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.

/ikh