Re: debate on 700 threads vs asynchronous code

[Matti Aarnio <matti.aarnio@zmailer.org>]

On Fri, Jan 24, 2003 at 04:53:46PM -0600, Corey Minyard wrote:
...
> I would disagree.  One thread per connection is easier to conceptually 
> understand.  In my experience, an event-driven model (which is what you 
> end up with if you use one or a few threads) is actually easier to 
> correctly implement and it tends to make your code more modular and 
> portable.

  An old thing from early annals of computer science (I browsed Knuth's
"The Art" again..) is called   Coroutine.

Gives you "one thread per connection" programming model, but without
actual multiple scheduling threads in the kernel side.

Simplest coroutine implementations are truly simple.. Pagefull of C.
Knuth shows it with very few MIX (assembly) instructions.

Throwing in non-blocking socket/filedescriptor access, and in event
of "EAGAIN", coroutine-yielding to some other coroutine, does complicate
things, naturally.

Good coder finds balance in between various methods, possibly uses
both coroutine "userspace threads", and actual kernel threads.

Doing coroutine library all in portable C (by means of setjmp()/longjmp())
is possible, but not very efficient.  A bit of assembly helps a lot.

> -Corey

/Matti Aarnio