Re: Crash in CFReadStreamOpen
Re: Crash in CFReadStreamOpen
- Subject: Re: Crash in CFReadStreamOpen
- From: Quinn <email@hidden>
- Date: Fri, 29 May 2009 10:56:13 +0100
At 15:49 +0200 28/5/09, Benoit Foucher wrote:
It's actually not clear to me how I'm supposed to use run loops if
the APIs aren't thread safe or why the different methods to register
a source with a run loop provide a run loop parameter. Suppose I
want a thread pool to handle IO for multiple network connections
(either using the CFSocket or CFStream APIs). How can I register the
network connections with the run loop of each thread from the pool?
If I can't call CFRunLoopAddSource or
CFReadStreamScheduleWithRunLoop from a separate thread, I suppose
I'll have to somehow register the source from each thread. If that's
the case, do you have any recommendation on the best way to do this?
I'm not saying that you can't do cross thread source scheduling and
unscheduling. What I'm saying is that this is not a well-trodden
path, and if there are bugs in the system you're likely to be the one
finding them. Personally, that's not the way I like to travel.
If you do find specific, reproducible problems with this, feel free
to file a bug about them.
<http://developer.apple.com/bugreporter/>
The way I usually do this is... well, I usually try to keep
everything running on the main thread. Unless you have an extremely
performance sensitive application this is usually good enough. One
step up in complexity is to put all of the I/O (as opposed to GUI or
CPU) operations on one thread. This will help with performance
because I/O operations won't be block by the high latency GUI or
CPU-bound operations. Finally, once I've shown that it's worth the
effort, I'd consider a move to a multi-runloop design.
Within my multi-runloop design I would put each source on just one
runloop. That each, each thread in my pool would be responsible some
some set of sources, and sources wouldn't move between threads. You
can then have each thread listen for new work, create the sources
associated with that work, and schedule those sources on its own
runloop.
S+E
--
Quinn "The Eskimo!" <http://www.apple.com/developer/>
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden