Re: threads vs run-loops for keeping your GUI responsive
Re: threads vs run-loops for keeping your GUI responsive
- Subject: Re: threads vs run-loops for keeping your GUI responsive
- From: Erik Buck <email@hidden>
- Date: Fri, 9 Dec 2005 13:26:12 -0500
Greg Herlihy's post was one of the best I have read all year. He
very neatly describes the issue of user responsiveness when long
running operations are needed.
I strongly support Mr. Herlihy's suggestion to use multiple processes
instead of multiple threads. Cocoa's distributed objects, message
queues, pipes, and shared memory can all be used between the
processes as needed.
In the Unix world, threads were invented as "light weight" processes
in order to reduce the cost of starting "heavy weight" processes.
The light weight of threads was achieved by dropping the memory
protection that Unix processes enjoy with respect to each other. In
my opinion, the loss of memory protection was a side effect and not
the primary intent. The loss of memory protection has huge negative
consequences, but programmers have tended to take advantage of the
lost protection as a perceived benefit to optimize memory based
communication between threads. (at the expense of huge complexity)
Now, step back for a moment and remember that one of the principal
technical criticisms of Mac OS 9 and its predecessors was the lack of
inter-process memory protection. There are good reasons for those
criticisms... nobody can take a modern programming environment
seriously if it doesn't provide basic memory protections.
Let me say it another way: Creating a correct program is very hard in
a single threaded process. It is so hard in a multi-threaded process
that in my opinion it is almost never justified to use multiple
threads per process for most types of application.
Ironically, multi-threaded programming is still novel enough in the
Unix world 10-15 years after it became commonly available that
programmers want to use it as a cool trick. In my opinion, the
original reason for introducing threading was to reduce process
creation time, but process creation is so fast on modern systems that
the original reason is no longer valid.
Now for my reluctant admission: I have written a lot of multi-
threaded code for use on multi-processor systems. Sometimes it is
necessary to squeeze every last bit of performance out of a system,
and using one high priority computation thread locked down to each
processor is currently one of the only ways to get the maximum
possible performance from a multi-processor system.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden