[Interest] Running Qt in a shared library on a Mac

[Till Oliver Knoll]

Am 24.01.2014 um 10:17 schrieb Till Oliver Knoll <till.oliver.knoll at gmail.com>:

> Am 24.01.2014 um 03:22 schrieb Thiago Macieira <thiago.macieira at 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)! ...
>> 
>> 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' 

Hmmm, interesting, I just stumbled across the following in some "random corner of the Apple Cocoa documentation" about "autorelease pools":

"Note: If you create secondary threads using the POSIX thread APIs instead of NSThread, you cannot use Cocoa unless Cocoa is in multithreading mode. Cocoa enters multithreading mode only after detaching its first NSThread object. To use Cocoa on secondary POSIX threads, your application must first detach at least one NSThread object, which can immediately exit. You can test whether Cocoa is in multithreading mode with the NSThread class method isMultiThreaded."

 https://developer.apple.com/library/ios/documentation/cocoa/conceptual/MemoryMgmt/Articles/mmAutoreleasePools.html#//apple_ref/doc/uid/20000047-1041876

Or in other words: if you create your "GUI thread" with the POSIX API, but *do not* instantiate and run an instance of NSThread before, then Cocoa still thinks it is "in single thread mode" and hence assertion checks lie [NSThread isMainThread] /might/ then be omitted.

However the wording "you cannot use Cocoa unless Cocoa is in multithreading mode" (*) could also mean that there is yet another assertion which will make sure that your "NSApplication event queue in GUI thread"-approach fails yet again - but it could also mean that as long as you would restrict all your Cocoa calls to that "GUI thread" then that could still work... to be verified ;)

(Unless off course some Cocoa classes themselves will create NSThreads and then later on Cocoa will figure out that it is indeed multithreaded and not in the main thread and *bang*!)

Cheers, Oliver


(*) Note that some Cocoa classes are indeed thread-safe. Even painting on the screen from some "non-main" thread is supported to some extend. It's just like the event queue and some other classes like the NSUndoManager seem to insist to exclusively live in the "main" thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20140124/b7a32882/attachment.html>