From: Dan Kegel <dank@alumni.caltech.edu>
To: "linux-kernel@vger.rutgers.edu" <linux-kernel@vger.rutgers.edu>
Cc: raster@rasterman.com
Subject: re: RasterMan on linux and threads
Date: Fri, 17 Dec 1999 07:02:00 -0800 [thread overview]
Message-ID: <385A5068.B4490833@alumni.caltech.edu> (raw)
re http://kernelnotes.org/lnxlists/linux-kernel/lk_9912_03/msg00480.html
Rasterman is wrong in saying that all threads run on the same
processor, but everything else he says about threads is spot on:
unless you have a real good reason to create a thread, don't.
Ousterhout certainly agrees. See his slides on "Why threads are bad (usually)"
at http://www.scriptics.com/people/john.ousterhout/
Earlier in his news page, Raster says:
> The [imlib2] API changed a lot recently - it's now context based (you set
> the current context) and it uses that current context for almost all
> calls. It means many fewer parameters to many calls - but it also means
> Imlib2 is NOT thread-safe as the context is global. If anyone wants to
> work on making it thread safe - there's source code and send patches -
> but I don't see much value in it. Do all your graphics work in 1 thread.
Wow, deja vu. Right on the heels of Jim Gettys' post on the same subject,
http://kernelnotes.org/lnxlists/linux-kernel/lk_9912_03/msg00096.html
Raster, you might want to read Jim's post. X calls use lots of context
parameters (like old imlib), OpenGL calls use none (like new imlib2), and
now they both wish they'd used a single one (i.e. an object oriented approach).
And you might want to modify your statement that threads always run on the same
CPU...
- Dan
--
(The above is just my personal opinion; I don't speak for my employer,
except on the occasional talk show.)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
reply other threads:[~1999-12-17 15:21 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=385A5068.B4490833@alumni.caltech.edu \
--to=dank@alumni.caltech.edu \
--cc=linux-kernel@vger.rutgers.edu \
--cc=raster@rasterman.com \
/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