Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » OS X Fullscreen Window in incorrect thread (per Xcode)

Credits go to Chris Katko, Peter Hull, and SiegeLord for helping out!
This thread is locked; no one can reply to it. rss feed Print
OS X Fullscreen Window in incorrect thread (per Xcode)
calteran
Member #16,790
January 2018

Just getting started with Allegro 5.2.3, and I'm following the tutorial for creating a window. All I've changed is adding the flag for making the window fullscreen. When running on OS X (10.13.2) via Xcode, I get an error reported in the console saying that I'm invoking the UI from the wrong thread. I've done a bit of Googling on this, but haven't found a definitive fix. Has anyone else seen this issue/know a fix?

Relevant code snippet:

int main(int argc, char **argv){
    
    ALLEGRO_DISPLAY *display = NULL;
    
    if(!al_init()) {
        cerr << "failed to initialize allegro!" << endl;;
        return -1;
    }
    
    al_set_new_display_flags(ALLEGRO_FULLSCREEN_WINDOW);
    
    display = al_create_display(800, 600);  // <<--- ERROR OCCURS HERE
    
    //...

    return 0;
}

And the error reported in the console is:

=================================================================
Main Thread Checker: UI API called on a background thread: -[NSOpenGLView initWithFrame:]
PID: 24293, TID: 8372435, Thread name: (none), Queue name: com.apple.root.default-qos.overcommit, QoS: 21
Backtrace:
4   liballegro.5.2.dylib                0x000000010036671d create_display_win + 168
5   liballegro.5.2.dylib                0x0000000100329670 al_create_display + 40
6   MyApp                               0x0000000100001d07 _al_mangled_main + 423
7   liballegro.5.2.dylib                0x0000000100368f99 +[AllegroAppDelegate app_main:] + 23
8   Foundation                          0x00007fff2e013e48 _NSThread__start_ + 1197
9   libsystem_pthread.dylib             0x00000001004576b9 _pthread_body + 340
10  libsystem_pthread.dylib             0x0000000100457565 _pthread_body + 0
11  libsystem_pthread.dylib             0x0000000100456c55 thread_start + 13
2018-01-07 08:23:26.166147-0800 MyApp[24293:8372435] [reports] Main Thread Checker: UI API called on a background thread: -[NSOpenGLView initWithFrame:]
PID: 24293, TID: 8372435, Thread name: (none), Queue name: com.apple.root.default-qos.overcommit, QoS: 21
Backtrace:
4   liballegro.5.2.dylib                0x000000010036671d create_display_win + 168
5   liballegro.5.2.dylib                0x0000000100329670 al_create_display + 40
6   MyApp                               0x0000000100001d07 _al_mangled_main + 423
7   liballegro.5.2.dylib                0x0000000100368f99 +[AllegroAppDelegate app_main:] + 23
8   Foundation                          0x00007fff2e013e48 _NSThread__start_ + 1197
9   libsystem_pthread.dylib             0x00000001004576b9 _pthread_body + 340
10  libsystem_pthread.dylib             0x0000000100457565 _pthread_body + 0
11  libsystem_pthread.dylib             0x0000000100456c55 thread_start + 13
Program ended with exit code: 0

Note: the "error" is not a complier/debugger error, but simply output to the console.

SiegeLord
Member #7,827
October 2006
avatar

Interesting, thanks for reporting this! I don't think I've ever seen the error in my XCode, but I think I'm still on 10.12. Does the app still work despite the error? It's not something you can fix, however, we'll need to fix Allegro.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Chris Katko
Member #1,881
January 2002
avatar

I've heard HORRIBLE things about High Sierra OS X.

[edit]

Hmm this reports:

Quote:

This is not an iOS 11 issue per se. We have extensively tested the v100.1 runtime with some of the iOS 11 betas and the recent GM and found no issues that affect functionality or usability of apps built with the runtime. This message is developer warning being generated by Xcode 9 because it has a new main-thread-checker that is enabled by default to look for potential problems in accessing Apple's UIKit APIs. It has flagged a couple of instances where we need to tweak how we use these APIs and be fully compliant with Apple's guidance. We are working on it and hope to release an update soon that should be free of any warnings, but in the meantime don't let it prevent you from supporting iOS 11 for your apps. Based on our testing, we are confident that the existing runtime works just as well on iOS 11.

https://community.esri.com/thread/201929-ios-11-threading-issue

So its not an error, but a warning...

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs

Peter Hull
Member #1,136
March 2001

The faulty line is here:
https://github.com/liballeg/allegro5/blob/da4b7162941b8f364a02bba85b5c2a1b168f5478/src/macosx/osxgl.m#L1578

Note the logic is to create a temporary fullscreen view to check it's possible,then delete it, then create the actual window. (I don't know why this is, it will be in the history)
Creating the actual window is carefully done on the main thread but the temp window is done on the current thread.
https://github.com/liballeg/allegro5/blob/da4b7162941b8f364a02bba85b5c2a1b168f5478/src/macosx/osxgl.m#L1630

I think the best way would be to add the 'test creation' code as a method on ALDisplayHelper then call it with performSelectorOnMainThread: as is done for the actual window creation.

Every so often Apple tighten up the main thread only rule, it used to be you could get away with much more.

Pete

calteran
Member #16,790
January 2018

Apologies for letting this go stale without a response.

Thanks for the perspective on this. Currently my (skeleton) program functions fine, just with the noted output in the console. From Apple's documentation, it looks as though this won't happen when compiled with a Release profile, so this is no more than a development nuisance. I assume there's no workaround other than re-writing and recompiling the library with the test fullscreen function on the correct thread?

Regardless, this is my first introduction to the Allegro community, and it's gratifying to get a substantive response so quickly. I'm excited to see what's possible with this library :)

Peter Hull
Member #1,136
March 2001

OK, I've done a bit more reading about this. It's not a new restriction in MacOS as such, rather a new tool which is enabled by default when running in Xcode.

You can activate it from the command line like so

DYLD_INSERT_LIBRARIES=/Applications/Xcode.app/Contents/Developer/usr/lib/libMainThreadChecker.dylib ./ex_fs_window

I see there are more things it picks up than just the example given by calteran.

Is anyone working on Mac at the moment, I suppose I could fix it if there's no-one else. Siegelord, what do you think?

SiegeLord
Member #7,827
October 2006
avatar

I was thinking of looking at this at some point (I do have a Mac), but it's not urgent as it doesn't appear to break anything. Filed an issue for this so it's not forgotten: https://github.com/liballeg/allegro5/issues/876

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Go to: