Comments on: Productive Waste of Time: Figuring out the main thread http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/ On Mac OS X programming Thu, 12 Aug 2010 19:25:08 -0400 http://wordpress.org/?v=2.8.5 hourly 1 By: Adrian Bool http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-15541 Adrian Bool Mon, 31 Mar 2008 17:31:09 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-15541 If you needed this information in your application, would you not just set a global pointer to it as the app starts up - and you know you are in the main thread - for later use..? Gets rid of any possible deadlocks... If you needed this information in your application, would you not just set a global pointer to it as the app starts up – and you know you are in the main thread – for later use..? Gets rid of any possible deadlocks…

]]> By: JustBill http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-7871 JustBill Tue, 06 Nov 2007 18:18:08 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-7871 none of what you are suggesting is necessary at all. i'm relatively new to the Mac platform, but at least from what i can tell you have everything you need in the leopard release (not sure if it was there before). the major reason to run performSelectorOnMainThread is to ensure secondary threads don't update the UI since thread safe access is accomplish through thread affinity using NSRunLoop. you can call performSelectorOnMainThread on any object or class, and providing the selector is implemented via a matching method, Cocoa will execute that method on the "main" thread. whomever is writing the code should be aware what their doing;nonetheless, you can ensure it by doing something similar to the following: -(void)doSomething: (NSNumber*)someValue { if (![NSThread isMainThread]) [self performSelectorOnMainThread:@selector(doSomething:) withObject:somevalue waitUntilDone:NO]; else [_txtField1 setIntValue: [someValue intValue]]; } none of what you are suggesting is necessary at all. i’m relatively new to the Mac platform, but at least from what i can tell you have everything you need in the leopard release (not sure if it was there before).

the major reason to run performSelectorOnMainThread is to ensure secondary threads don’t update the UI since thread safe access is accomplish through thread affinity using NSRunLoop.

you can call performSelectorOnMainThread on any object or class, and providing the selector is implemented via a matching method, Cocoa will execute that method on the “main” thread.

whomever is writing the code should be aware what their doing;nonetheless, you can ensure it by doing something similar to the following:

-(void)doSomething: (NSNumber*)someValue
{
if (![NSThread isMainThread])
[self performSelectorOnMainThread:@selector(doSomething:)
withObject:somevalue
waitUntilDone:NO];
else
[_txtField1 setIntValue: [someValue intValue]];
}

]]> By: Adam Nohejl http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-5777 Adam Nohejl Sat, 29 Sep 2007 19:13:12 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-5777 Suppose that the main thread is busy (it doesn't cycle through its run loop for the moment) - then the +mainThread method gets blocked waiting. Suppose that, for some reason, the main thread will want to stay like this until some work is done in the detached thread (there may be for instance a lock it wants to acquire), but the detached thread is now blocked waiting for a selector to be executed on the main thread... Just a hypothetical scenario, but anyway, I don't think this way of determining the main thread is a good idea. I would either use a different method or set the main thread static var beforehand (not very elegant). Suppose that the main thread is busy (it doesn’t cycle through its run loop for the moment) – then the +mainThread method gets blocked waiting. Suppose that, for some reason, the main thread will want to stay like this until some work is done in the detached thread (there may be for instance a lock it wants to acquire), but the detached thread is now blocked waiting for a selector to be executed on the main thread…

Just a hypothetical scenario, but anyway, I don’t think this way of determining the main thread is a good idea. I would either use a different method or set the main thread static var beforehand (not very elegant).

]]> By: Ofri Wolfus http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-3874 Ofri Wolfus Wed, 18 Jul 2007 11:33:53 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-3874 Just for fun, here is another approach which doesn't block the caller thread (yes, I know I'm leaking the main thread instance but it shouldn't go away anyhow) <code>static NSThread *_mainThread = nil; static __attribute__((constructor)) void _DPInitMainThread(void) { _mainThread = [[NSThread currentThread] retain]; } + (NSThread *)mainThread { return _mainThread; }</code> Just for fun, here is another approach which doesn’t block the caller thread (yes, I know I’m leaking the main thread instance but it shouldn’t go away anyhow)
static NSThread *_mainThread = nil;

static __attribute__((constructor)) void _DPInitMainThread(void) {
_mainThread = [[NSThread currentThread] retain];
}

+ (NSThread *)mainThread {
return _mainThread;
}

]]> By: Martin Wennerberg http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-2135 Martin Wennerberg Tue, 08 May 2007 06:48:31 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-2135 Method names starting with _ are reserved for Apple private use so I would suggest renaming the _setMainThread method to make sure that you aren't overriding something in Apple's implementation on NSThread. (http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_950_section_11.html) Also, as Apple might implement methods called -isMainThread and +mainThread in future versions of Mac OS X I would call them something that Apple wouldn't. Method names starting with _ are reserved for Apple private use so I would suggest renaming the _setMainThread method to make sure that you aren’t overriding something in Apple’s implementation on NSThread. (http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_950_section_11.html)

Also, as Apple might implement methods called -isMainThread and +mainThread in future versions of Mac OS X I would call them something that Apple wouldn’t.

]]> By: Jesper http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-2065 Jesper Sun, 06 May 2007 09:05:14 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-2065 Convincing. Convincing.

]]> By: mr_noodle http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-1952 mr_noodle Tue, 01 May 2007 16:14:12 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-1952 Yes, I know of what you speak, which is, of course, of NOTHING, because there is NOTHING being divulged about future OS releases that may or may not exist. Nothing to see here. La-di-da. Oh, look over there! Yes, I know of what you speak, which is, of course, of NOTHING, because there is NOTHING being divulged about future OS releases that may or may not exist. Nothing to see here. La-di-da. Oh, look over there!

]]> By: Chris Ryland http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/comment-page-1/#comment-1951 Chris Ryland Tue, 01 May 2007 16:04:08 +0000 http://www.noodlesoft.com/blog/2007/05/01/productive-waste-of-time-figuring-out-the-main-thread/#comment-1951 Luckily, I believe this code, along with many other good thread-related activities, will no longer be an issue in a few momths. Ahem. ;-) Luckily, I believe this code, along with many other good thread-related activities, will no longer be an issue in a few momths. Ahem. ;-)

]]>