[lkml]   [2003]   [Jan]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: debate on 700 threads vs asynchronous code
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
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:32    [W:0.036 / U:7.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site