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