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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.