FROM : Jens Alfke
DATE : Sat Mar 29 18:05:14 2008
On 29 Mar '08, at 6:44 AM, Trygve Inda wrote:
> Can I call the following from a thread?
Apologies for giving an opinion instead of an answer ... but here's my
opinion. I've always avoided calling AppKit from multiple threads.
Instead I run the app's entire UI on the main thread, use asynchronous
APIs as much as possible (e.g. for networking), and use background
threads only when necessary and only for non-UI tasks.
Partly this comes from my previous experience with Java, where apps
spawn threads promiscuously and tend to do UI tasks on many of them at
once. This made implementing the AWT graphics library (the platform-
specific pieces of it) pretty hellish, since everything had to be
thread-safe. This added tons of complexity to the code, and meant lots
of race conditions and deadlocks to debug. I left that job vowing
never to create a thread ever again :)
Multiprocessing is an unsolved problem — no one's discovered a really
good abstraction for it that makes code simple and reliable. It's like
memory management pre-garbage collection, or control flow pre-
structured programming. There's a great paper on the topic, "The
Trouble With Threads" by Edward Lee of UC Berkeley:
http://www.artist-embedded.org/docs/PositionPapers/Lee_Threads_May2006.pdf
"For concurrent programming to become mainstream,we must discard
threads as a
programming model.Nondeterminism should be judiciously and carefully
introduced
where needed,and it should be explicit in programs."
By way of answering … I _believe_ you can create and draw into
NSImages on background threads; but I'm not certain. Drawing into the
same image from multiple threads at once, though, could likely get you
into trouble.
—Jens
DATE : Sat Mar 29 18:05:14 2008
On 29 Mar '08, at 6:44 AM, Trygve Inda wrote:
> Can I call the following from a thread?
Apologies for giving an opinion instead of an answer ... but here's my
opinion. I've always avoided calling AppKit from multiple threads.
Instead I run the app's entire UI on the main thread, use asynchronous
APIs as much as possible (e.g. for networking), and use background
threads only when necessary and only for non-UI tasks.
Partly this comes from my previous experience with Java, where apps
spawn threads promiscuously and tend to do UI tasks on many of them at
once. This made implementing the AWT graphics library (the platform-
specific pieces of it) pretty hellish, since everything had to be
thread-safe. This added tons of complexity to the code, and meant lots
of race conditions and deadlocks to debug. I left that job vowing
never to create a thread ever again :)
Multiprocessing is an unsolved problem — no one's discovered a really
good abstraction for it that makes code simple and reliable. It's like
memory management pre-garbage collection, or control flow pre-
structured programming. There's a great paper on the topic, "The
Trouble With Threads" by Edward Lee of UC Berkeley:
http://www.artist-embedded.org/docs/PositionPapers/Lee_Threads_May2006.pdf
"For concurrent programming to become mainstream,we must discard
threads as a
programming model.Nondeterminism should be judiciously and carefully
introduced
where needed,and it should be explicit in programs."
By way of answering … I _believe_ you can create and draw into
NSImages on background threads; but I'm not certain. Drawing into the
same image from multiple threads at once, though, could likely get you
into trouble.
—Jens
| Related mails | Author | Date |
|---|---|---|
| Trygve Inda | Mar 29, 14:44 | |
| Jens Alfke | Mar 29, 18:05 | |
| Adam R. Maxwell | Mar 29, 18:54 | |
| Trygve Inda | Mar 29, 20:20 | |
| Adam R. Maxwell | Mar 29, 20:48 | |
| Thomas Engelmeier | Mar 30, 15:10 | |
| Adam R. Maxwell | Mar 30, 17:01 | |
| Trygve Inda | Mar 30, 17:34 | |
| Jens Alfke | Mar 30, 19:02 | |
| glenn andreas | Mar 30, 19:14 | |
| Trygve Inda | Mar 30, 22:21 | |
| glenn andreas | Mar 30, 22:35 | |
| Thomas Engelmeier | Mar 31, 12:30 |






Cocoa mail archive

