Le 11 avr. 08 à 19:14, Tom Harrington a écrit :
On Fri, Apr 11, 2008 at 3:53 AM, Micha Fuhrmann <[EMAIL PROTECTED]>
wrote:
Ok, I've used - (void)performSelectorOnMainThread:(SEL)aSelector
withObject:(id)arg waitUntilDone:(BOOL)wait and it's fine one, you've
pointed t what was wrong, however I thought that because the method
sendLogs
was invoqued by an instance that is alive during the whole app
lifetime it
would be OK. Turns out that NSURLConnections called indirectly by a
short
time run loop to the main thread doesn't follow up.
Right, the run loop needs to keep going at least until NSURLConnection
is finished. Although secondary threads don't automatically get run
loops, it's OK to create new run loops in different threads if it's
appropriate to your situation. Using -performSelectorOnMainThread: is
one way around the problem, but it might make more sense to just give
the thread its own run loop. It all depends on your app architecture.
NSRunloop documentation disagree:
In general, your application does not need to either create or
explicitly manage NSRunLoop objects. Each NSThread object, including
the application’s main thread, has an NSRunLoop object automatically
created for it as needed. If you need to access the current thread’s
run loop, you do so with the class method currentRunLoop.
Even CFRunLoop documentation disagree:
There is exactly one run loop per thread. You neither create nor
destroy a thread’s run loop. Core Foundation automatically creates it
for you as needed.
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
