Am 24.01.2014 um 03:22 schrieb Thiago Macieira <thiago.macie...@intel.com>:
> On quinta-feira, 23 de janeiro de 2014 21:47:25, Till Oliver Knoll wrote: >> For the curious: trying to instantiate an NSApplication within an >> NSThread does /not/ work (and the same then holds off course for a >> QApplication)! I got indeed an assert, probably the same which was >> already mentioned in the Stack Overflow question. > > The same goes for QApplication / QThread. > > But what happens if you use pthread_create instead? I did evaluate whether my start thread (where the function main() is being executed) is already considered by Cocoa to be the "main thread" with [NSThread isMainThread] (*) and it already returned 'YES' - that was the very first statement after main() (except that @autoreleasepool thing, I don't know what kind of code that generates). At that point I did not have any Cocoa instance instantiated (maybe that @autoreleasepool did?). Since I /assume/ that you cannot (easily) fool that static NSThread:isMainThread method by creating a thread different than with NSThread it would still return 'NO', even within a "POSIX created thread. And I assume it is that very "isMainThread" method which is part of that assert statement which makes some "NSUndoManager" (?) bail out (which is instantiated when starting the event loop with [NSApplicationMain run]). I assume there are several other such assert statements checking for "isMainThread" distributed across several Cocoa classes. Interestingly the first such statement was in the said NSUndoManager, and did not originate from NSApplication itself, which could explain why the documentation about that class is "a bit silent" on that matter ;) However ObjC "Categories" just came to my mind, if one really wants to go down the dirty road: one could add a category for the class NSThread and "override" the static method "isMainThread". (And yes, "Categories" in ObjC also change /instances/ which are not created by your own code, but by some other library such as Cocoa - very cool ObjC language/runtime feature! Even though "overriding" existing methods with Categories is considered "dirty" and not quite guaranteed by the runtime which method is really called in the end, especially if the method to be overwritten was itself already implemented in a Category (**): it's more like a "first come, first served" principle without knowing who comes first. But since we want to get dirty here, that's okay.) So if you would override NSThread:isMainThread and always return 'YES' and otherwise make sure that you restrict all "GUI/Cocoa" activity to your newly created "GUI thread", then /maybe/ you could move the Cocoa stuff in a different thread. Probably other Cocoa stuff would now break because isMainThread would now always return 'YES' - you could try to fight that my tweaking your Category implementation which would return 'NO' then and when, e.g. once the shared instance of NSApplication exists or so - but you get the idea where that leads to >:) Cheers, Oliver (*) which by the way is the ObjectiveC way to say e.g. QThread::isMainThread(), that is calling a static “method” (aka “selector” in ObjC speak) (**) http://stackoverflow.com/questions/14259517/override-a-method-in-objective-c-via-category
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
