Re: Proper time to thread?
Re: Proper time to thread?
- Subject: Re: Proper time to thread?
- From: Peter Sichel <email@hidden>
- Date: Fri, 31 May 2002 14:41:37 -0400
At 1:45 PM +0100 5/31/02, Quinn wrote:
There's no "in general" answer to this question. Here are the
issues as I see them.
btw If anyone else has any thoughts on this issue I'd love to hear
them. I think this would make a great DTS Q&A.
<http://developer.apple.com/qa/index.html>
...
User Interface
--------------
If your networking and UI are intimately intertwined, you are better
off using the runloop model. That way your network code can access
UI constructs without any special locking or message passing.
Quinn's response is excellent as usual. I'll just add that separating
the UI from the networking code is often a useful design pattern
(ala MVC). Suppose you want to do a faceless background version,
make your application scriptable, or remote the user interface
(via Distributed Objects for example). If you allow for a clean
separation between networking and UI, these become easier.
I can also offer my own observation that the native BSD networking
APIs are designed for threaded blocking (using select() and others).
Under the hood, the run loop methods create a shared thread that does
this for you. The only advantage of doing it yourself is that you can
gain a little more flexibility and performance if you need it. Each
thread is eligible to run on a different CPU in a multiprocessor
system for example.
To be honest, I was skeptical of the BSD threaded blocking model
at first. It can't possibly offer the same raw speed as the
interrupt driven notifiers of Open Transport because you have
to wait for the kernel to get around to scheduling your thread.
The advantage of the threaded or run loop model is that once your thread
is awakened, you get to run in the normal application context.
You don't have to worry about interrupt safe APIs and synchronization.
Even though it's possible to write faster servers with interrupt
driven notifier model, most developers never took full advantage
of this.
Being guaranteed regular CPU cycles via preemptive scheduling
along with the simplicity of the run loop or threaded blocking
model does good things for networking.
- Peter
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.