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