From: Dan Kegel <dank@kegel.com>
To: "Randy.Dunlap" <rddunlap@osdl.org>
Cc: Matti Aarnio <matti.aarnio@zmailer.org>,
Corey Minyard <minyard@acm.org>,
Mark Mielke <mark@mark.mielke.cc>,
Mark Hahn <hahn@physics.mcmaster.ca>,
linux-kernel@vger.kernel.org
Subject: Re: debate on 700 threads vs asynchronous code
Date: Fri, 24 Jan 2003 16:11:35 -0800 [thread overview]
Message-ID: <3E31D637.1030306@kegel.com> (raw)
In-Reply-To: <Pine.LNX.4.33L2.0301241528100.9816-100000@dragon.pdx.osdl.net>
Randy.Dunlap wrote:
> On Sat, 25 Jan 2003, Matti Aarnio wrote:
>
> | 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. ...
> | 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.
There's also an elegant implementation that uses switch statements
or computed gotos; see http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html
I'm using it. It's a bit limited, but hey, it works for me.
> Davide Libenzi (epoll) likes and discusses coroutines on one of his
> web pages: http://www.xmailserver.org/linux-patches/nio-improve.html
> (search for /coroutine/)
IMHO coroutines are harder to use than either threads or nonblocking I/O.
Then again, I don't like Scheme; many things in this world are a matter of taste.
- Dan
--
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045
next prev parent reply other threads:[~2003-01-24 23:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.44.0301232144470.8203-100000@coffee.psychology.mcmaster.ca>
2003-01-24 8:21 ` debate on 700 threads vs asynchronous code Dan Kegel
2003-01-24 8:26 ` Mark Mielke
2003-01-24 22:53 ` Corey Minyard
2003-01-24 23:21 ` Matti Aarnio
2003-01-24 23:29 ` Randy.Dunlap
2003-01-25 0:11 ` Dan Kegel [this message]
2003-01-29 21:32 Dan Kegel
-- strict thread matches above, loose matches on Subject: below --
2003-01-29 17:26 Lee Chin
2003-01-30 9:36 ` Terje Eggestad
[not found] <Pine.LNX.4.44.0301241840450.11758-100000@coffee.psychology.mcmaster.ca>
2003-01-25 0:24 ` Dan Kegel
[not found] <Pine.LNX.4.44.0301232028480.980-100000@coffee.psychology.mcmaster.ca>
2003-01-24 2:04 ` Dan Kegel
2003-01-24 1:46 Dan Kegel
2003-01-24 0:07 Lee Chin
2003-01-23 23:19 Lee Chin
2003-01-23 23:28 ` Larry McVoy
2003-01-23 23:31 ` Ben Greear
2003-01-27 9:48 ` Terje Eggestad
2003-01-27 21:48 ` Bill Davidsen
2003-01-27 22:08 ` Bill Davidsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E31D637.1030306@kegel.com \
--to=dank@kegel.com \
--cc=hahn@physics.mcmaster.ca \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@mark.mielke.cc \
--cc=matti.aarnio@zmailer.org \
--cc=minyard@acm.org \
--cc=rddunlap@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox