Peter Petrov wrote:
Agreed threads are alternative, but only for small servers without high scalability requirements (e.g. tens of thousands simultaneous HTTP keep-alive connections). The thread-per-connection model is outdated and in 2010 it's not a good idea to start a framework which relies on it.
Well, I'd actually argue the contrary now that we have 64 bit systems and the old issues of running out of VM addresses for stacks is gone. Having said that I too prefer async IO - but I'm really not sure many applications need more than 10k connections, and while I'd have baulked at that number of threads, I suspect that all the major server platforms can handle that many these days.
Coroutines could work, though I doubt the complexity (e.g. using yielding iterators with Spirit) or performance will be any better than simply using a FSM-based parser.
Well, I'd prefer an FSM based parser, but Spirit sucks for that, since its a pull parser and you are only able to get away with it by making assumptions about receiving a 'whole message' before starting the parse. Which implies either an assumption about some alignment of read with content delimiters, or that you pre-scan the content to find the delimiter - and process every byte twice. A well executed push parser need not do that, and ragel or re2c feeding lemon is the best approach I know of. I haven't tried the ragel author's parser. James