Re: is safari multi-threaded? : a theory question on threading
Re: is safari multi-threaded? : a theory question on threading
- Subject: Re: is safari multi-threaded? : a theory question on threading
- From: Bill Bumgarner <email@hidden>
- Date: Tue, 6 Mar 2007 20:46:49 -0800
On Mar 6, 2007, at 5:19 PM, Kevin Viggers wrote:
The answer can be found by reading this:
http://webkit.org/blog/?p=96
On 11-Jan-07, at 3:07 PM, John Stiles wrote:
A good way to find out would be to use Shark.
On Jan 11, 2007, at 1:42 PM, George Green wrote:
using safari, i notice that when i view a web page that has video
on it and switch to another web page the video slows down and
skips, pages with just audio will skip. when using firefox, i
don't see the same action. is this an example of threading in
use in firefox where the application the smooth playing of video
or audio in the background(ed) window. or is that safari being
well threaded is allowing the other application in the
foreground, (or window with focus), to have greater cpu time
slice or slices.
Maybe so. Maybe not. You could figure out exactly what is going on
with Shark, or by reading that post, or by pulling out the
programming Tarot cards and whipping up a great theory as to why the
behavior is the way it is (I'm only being half flip -- much of the
threading "solutions" I have seen over the years would have been
better served through design by tarot).
It could be implemented via threading or it might be implemented with
a single thread and some creative subdivision of the rendering (both
audio / graphics) algorithms. Or it could even been done with a sub-
process and some very creative use of shared memory or IPC to blast
said bits into the browser window.
To keep an application responsive under Mac OS X you have to *not
block the main event loop*. Period. Threads are a solution. And
a problem. A very big problem, unless you understand exactly what
the compiler is doing.
A well behaved application will focus as much CPU time as it can on
making whatever the user is currently focused on responsive -- both
passively (movies, audio) and actively (tracking input, the mouse,
etc). Likewise, a well behaved application will consume as little
CPU as possible either in the foreground or the background,
preferably less in the background.
This can mean any number of things. A background window with an
actively rendered calculation may choose to not render with as much
precision or a video may drop frames or maybe only a summary /
approximation of the data may be displayed.
First, decide on how you want the user to experience your app. Where
should the lines of high fidelity vs. low fideltiy be drawn? How
important is it to be 100% responsive all the time? Should your app
try to squeeze out every last drop of system performance for itself
or should it try to minimize memory and CPU usage such that it can
work in conjunction with other apps?
Once you have decided that, choose the best strategy for meeting said
needs. Threads might likely be the answer -- or, hopefully, "a
thread". Or not.
Keep in mind that threads are extremely amazingly bloody difficult to
get right. Really really hard. Outstandingly talented folks
completely screw up threads. "Get right" does not mean "works all
the time" -- I can't tell you the number of codebases I have dived
into that have attempted threading where "right" means "so many locks
that only one thread is executing at a time". No wins there.
I don't mean to discourage people from using threads. Threads
clearly solve a number of problems. But threading should not be
*the solution*. The solution should be a solution to "How do I
create an experience for my users exactly as I want it to be?".
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden