• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Mixing network code with NSThread
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Mixing network code with NSThread


  • Subject: Re: Mixing network code with NSThread
  • From: Chris Parker <email@hidden>
  • Date: Mon, 29 Jan 2007 23:08:31 -0800

Hello,

On Jan 29, 2007, at 10:34 PM, R. Tyler Ballance wrote:

I'm working on a bit of painful networking code that really sits mostly on top of BSD sockets (CFNetwork doesn't appear to be as well suited for serving data as it is consuming it) and I was hoping to avoid the pain and complexity of pthreads for this (entire) application and get away with segmenting my code adequately enough to use NSThread in the classical concurrent thread-based server model.

Is this an avenue I should be avoiding? The basic model of the code I don't think would change much if I used stock pthreads, I think I'm really just substituting pthread_create() with [NSThread detachWithSelector:] right after I would be blocking on the accept() calls. (Inside the detached thread of course the method would handle the network I/O and then appropriately disconnect the client and kill the thread after the operations are complete) It almost seems _too_ easy, and I've found that when something is as easy as it seems in threading, it's probably broken :)

IPC from the detached selector would be relatively simple posting of NSNotifications to the main thread for handling (with retained objects), so that's not what I'm worried about, it just seems weird to mingle BSD socket code and NSThread together...in the same class even!

There doesn't seem to be an explicit Core Foundation abstraction for using threads (excluding pthreads) so is mixing this code with NSThread a viable option?

Well, it sort of depends. :)

You might want to take a look at some examples that were written for WWDC 2005 that do networking in Cocoa. The CocoaEcho and CocoaHTTPServer examples show how to set up streams for both IPv4 and IPv6 on run loops and then handle the events that come in.

It's not too much of a stretch to put the server bits on an NSThread and then use whatever your ITC (inter-thread communication) of choice is to get data where you want it.

The CocoaEcho example is here:

	http://developer.apple.com/samplecode/CocoaEcho/index.html

and the CocoaHTTPServer (slightly more complicated) is here:

	http://developer.apple.com/samplecode/CocoaHTTPServer/index.html

If you're not going to grabbing lots of data off the wire or taking a long time process it, you can probably get away with letting the run loop deal with things; but if you really want to not block the main thread, then putting the server on a thread is probably the right thing. As usual, sampling/Sharking this is your friend in figuring out where to move things (or not as the case may be).

.chris

--
Chris Parker
Cocoa Frameworks
Apple, Inc.

_______________________________________________

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


References: 
 >Mixing network code with NSThread (From: "R. Tyler Ballance" <email@hidden>)

  • Prev by Date: Mixing network code with NSThread
  • Next by Date: Re: NSColor opacity
  • Previous by thread: Mixing network code with NSThread
  • Next by thread: Re: Mixing network code with NSThread
  • Index(es):
    • Date
    • Thread