Re: Proper time to thread?
Re: Proper time to thread?
- Subject: Re: Proper time to thread?
- From: Quinn <email@hidden>
- Date: Fri, 31 May 2002 13:45:47 +0100
At 11:25 -0500 30/5/02, Chilton Webb wrote:
In general, when should I use threading in networking code and when
should I not?
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>
Existing Code
-------------
If you have existing code that uses one model or the other, it's
easier to stay with that model. Switching models is a real pain.
Portability
-----------
If you need to port your code to another platform, or share existing
code with another platform, you should take into account the models
supported by that platform. For example, synchronous/blocking
network I/O from threads works on pretty much every platform (albeit
badly on Mac OS 9), however runloops are only available on Mac OS X.
However, there may be an appropriate substitute for runloops on your
target platforms (async notifiers on Mac OS 9, async WinSock on
Windows, non-blocking with select on other UNIXen).
State
-----
Threading is often easier if you have a protocol that maintains a lot
of state per connection. In a threaded application you maintain this
state in the local variables of each function you call, whereas in a
runloop-based application you have to explicitly manage this state in
a connection record. For example, POP client code is ideal for
threading because there's a lot of state maintained in the
connection, whereas SNMP code is ideal for a runloop because it's
basically a simple request/response protocol.
Data Dependencies
-----------------
Threading works best if each connection is largely independent. If
each connection accesses one central data structure (or, worse yet, a
complex set of data structures), threads are a pain because you're
continually locking and unlocking that data structure. A special
case of this point is UI code (see below).
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.
Efficiency
----------
If you have hundreds of simultaneous connections, using a thread per
connection is not efficient. Threading works best in the 0..100
connection range.
Cancellation
------------
Cancelling a connection in threaded code can be tricky. Responding
quickly to cancellation is generally much easier in runloop-based
code. Mind you, Mac OS X does support SO_RCVTIMEO and SO_SNDTIMEO
which makes cancellation a little easier (at the cost of burning some
CPU cycles).
S+E
--
Quinn "The Eskimo!" <
http://www.apple.com/developer/>
Apple Developer Technical Support * Networking, Communications, Hardware
_______________________________________________
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.