sometimes the game fails to start due to race condition somewhere?

[mnalis]

[xcb] Unknown sequence number while processing queue [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. main: ../../src/xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed. zsh: abort ./main /playseed

[mnalis]

Also, sometimes fails with:

% make build && ./main /playseed 3; echo $?
make: Nothing to be done for 'build'.
main: ../../src/xcb_io.c:239: poll_for_event: Assertion `dpy->xcb->event_owner == XlibOwnsEventQueue && !dpy->xcb->event_waiter' failed.
zsh: abort      ./main /playseed 3
134

[mnalis]

adding if idletime=10 then quit:=true; in journey.pas just before until quit in mainloop(), and running from shell with:

reset; (date; make build; failed=0; for c in `seq 1 100`; do 
./main /playseed 3; ret=$?;  [ $ret -ne 4 ] && let failed=failed+1;echo "test $c returns $ret" ; done; 
echo "failed=$failed") | ts| tee -a fail_log.txt

indicates in fails in about 3% of the cases when using OpenGL

[mnalis]

When using just SDL, without OpenGL, it does not seem to fail (but without OpenGL we lose resize / full screen capability)

[mnalis]

marked several variables used in multiple threads as volatile drops the failure rate to 2/200:

one is regular:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
main: ../../src/xcb_io.c:263: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.
Aug 03 14:38:42 test 72 returns 134

but other is new:

XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 92 requests (91 known processed) with 2 events remaining.
An unhandled exception occurred at $00007F8AF1FE539A:
EAccessViolation: Access violation
Aug 03 14:38:08 test 46 returns 1

[mnalis]

commenting out resizeWindow and/or glGenTextures in video_output() does not help to get rid of xcb_xlib_threads_sequence_lost.

[mnalis]

It turns out threads are HARD. Few more obvious things:

• we use global variables and update them from various threads (main thread, video_output, handle_keys). It is buggy. volatile might help in simplest cases, but we really need memory barriers, for example see this
• SDL is not thread safe (nor OpenGL stuff?). We should do SDL stuff from one thread only (and we currently do it from all three). See here
• lots of good info about caveats when using SDL in games can be found here. We should probably do all SDL stuff in one thread, and use events to communicate with it.

[mnalis]

however, increasing SDL_Delay(20) to SDL_Delay(50) in c_utils.c makes the problem go away on my machine, so I'll let it rest instead of rewriting graphic/audio/keyboard low-level implementation...

[mnalis]

This will probably be need to fixed properly... Few resources:

• "Can I call SDL video functions from multiple threads?" No, most graphics back ends are not thread-safe, so you should only call SDL video functions from the main thread of your application.

• https://wiki.libsdl.org/CategoryThread "You should not expect to be able to create a window, render, or receive events on any thread other than the main one"

  • https://github.com/Rust-SDL2/rust-sdl2/issues/318 "SDL_PollEvent(), SDL_WaitEvent() and SDL_PumpEvents() may only be called on the main thread"
  • The thread that created the main window is the only thread that can access it (including e.g. handling events).
  • opengl operations only in thread that created opengl context "IMG_Load and SDL_Surface are cpu bound, so loading and creating in a different thread is okay. If you are going to create a texture, which is gpu bound, you have to do it in your main thread or the thread, where you created the window with the opengl context(SDL uses opengl for acceleration). Because opengl isn’t multithreating capable, your way of doing it is right"
  • multithreading gains nothing and just increases complexity "If you receive input after (or during) the update cycle then you have to wait till the next update cycle before you'll see the effects. The same is true during rendering. You might as well just check for input before the update cycle and do it all singlethreaded.

  1 Input 2 Update Logic 3 Render 4 Goto 1"

  • main thread is the one that called SDL_SetVideoMode "SDL is not inherently an interrupt or event driven framework. IO occurs by reading events off of the event queue by calling SDL_WaitEvent or SDL_PollEvent. This must occur in the "main" thread, the one that called SDL_SetVideoMode."

• SDL 1.2 threading docs: "In general, you must be very aware of concurrency and data integrity issues when writing multi-threaded programs. Some good guidelines include:

  • Don't call SDL video/event functions from separate threads
  • Don't use any library functions in separate threads
  • Don't perform any memory management in separate threads
  • Lock global variables which may be accessed by multiple threads
  • Never terminate threads, always set a flag and wait for them to quit
  • Think very carefully about all possible ways your code may interact"

• very good SDL forum thread about threading issues in X

  • see docs about XInitThreads(), XLockDisplay() / XUnlockDisplay()
  • SDL_Lock_EventThread() by itself doesn't really do anything
  • SDL_LockSurface() / SDL_UnlockSurface() don't have anything to do with threads (and are probably NOP)

Tutorials

• lazyfoo.net SDL Multithreading
• lazyfoo.net SDL Semaphores and Mutexes
• lazyfoo.net SDL OpenGL and OpenGL basics
• sourceforge.net SDL threads
• sdl.beuc.net multithreading programming

[mnalis]

Current workflow is:

INITIALIZATION (THREAD 0)

main.pas -> starter.pas -> data.pas MAIN:

• initializecanary
• initializemod
  • C:sdl_mixer_init
  • SDL: Mix_OpenAudio(); audio_open = 1
• readygraph: C:SDL_init_video(screen)
  • SDL: SDL_Init(SDL_INIT_AUDIO | SDL_INIT_VIDEO)
  • SDL: sdl_screen = SDL_SetVideoMode / sdl_screen = SDL_CreateRGBSurface
  • SDL: SDL_ShowCursor(SDL_DISABLE)
  • C:DrawPixel
    • SDL: SDL_MapRGB(sdl_screen, ...)
  • SDL: SDL_Flip(sdl_screen) // display
  • SDL: SDL_CreateThread(video_output, NULL) // new thread: 1
  • SDL: SDL_CreateThread(handle_keys, NULL) // new thread: 2
• readygraph: loadpal('data/main.pal')
  • data.pas: read(palfile,colors);
• readygraph: C:set256colors(colors)
  • C: memcpy(palette, pal, 256 * 3);
• journey.pas: mainloop [...]
  • C: mouse_get_status
  • C: return mouse_buttons;
  • C: mouse_show
  • C: showmouse=1;
  • C: move_mouse
  • SDL: SDL_WarpMouse
  • C: key_pressed, readkey
  • C: return keypressed; lookup C tables and return key;
  • C: play_mod
  • SDL: Mix_LoadMUS, Mix_PlayMusic, Mix_VolumeMusic
  • SDL: Mix_HookMusicFinished(musicDone) // initialize callback when music done!
  • C: setrgb256
  • C: palette[palnum].r = r; // g; b;
  • C: circle
  • C: draw_pixel()
    • C: v_buf[x + 320 * y] = cur_color
  • C: scale_img
    • C: fpc_screentype_t memcopy() alike
  • C: various other functions, using one of above models.... // most important ones using SDL or library/syscalls

CALLBACKS

• C: musicDone
  • SDL: Mix_HaltMusic, Mix_FreeMusic

video_output (THREAD 1)

• while (!video_stop) loop
  • C: if init_flag == 0: init_opengl()
  • SDL: SDL_SetVideoMode, SDL_GL_SetAttribute, SDL_WM_SetCaption...
  • OGL: glEnable, glShadeModel, glClearStencil, glGenTextures, ... gl
  • SDL, OGL: resizeWindow()
  • C: if resize: resizeWindow()
  • SDL, OGL: resizeWindow()
  • C: DrawPixel(sdl_screen...
  • SDL: SDL_MapRGB
  • C: sdl_screen[xxx] = yyy;
  • SDL: SDL_Flip(sdl_screen) // display
  • OGL: glLoadIdentity, glClear, glEnable, glBegin/glEnd, glFlush, SDL_GL_SwapBuffers
  • C: nanosleep
• C: video_done = 1;
• SDL: SDL_Quit

handle_keys (THREAD 2)

• while (!video_stop) loop
  • SDL: SDL_PollEvent(&event)
  • if event.type == SDL_QUIT:
    • C: stop_video_thread(): video_stop=1;
    • C: normal_exit = 0;
    • C: all_done: musicDone(); video_stop = 1; wait for them to finish
  • if event.type == SDL_KEYDOWN:
    • C: check arrays, update key_,
  • if event.type == SDL_MOUSEMOTION:
    • C: update mouse_x, mouse_y
  • if event.type == SDL_VIDEORESIZE:
    • C: resize = 1; resize_x = event.resize.w, resize_y=event.resize.h
  • SDL: SDL_Delay(50) // critical, crashes often without it!
• keys_done = 1

[mnalis]

Simplified current state:

• PASCAL (thread 0)

  • initialize
  • SDL: Mix_OpenAudio initialize (create its own async callback musicDone)
  • SDL: SDL_Init, SDL_SetVideoMode
  • SDL: create threads video_output and handle_keys
  • mainloop - almost infinite loop
  • update pascal screen[] 320x200 array
  • SDL: call various SDL:Mix and SDL_ video functions

• video_output (thread 1) almost-infinite loop

  • init_flag: SDL, OGL
  • resize flag: SDL, OGL
  • SDL, OGL for display from pascal screen[] array to real display, etc.

• handle_keys (thread 2) almost-infinite loop

  • SDL: SDL_PollEvent()
  • SDL: Mix*
  • update C flag variables (which should be volatile)
  • SDL: SDL_Delay(50) // critical, crashes often without it!

[mnalis]

What needs to change:

• merge handle_keys and video_output into one thread
• modify PASCAL (thread 0) to:
  • never call any SDL functions except one SDL_createthread()
  • instead it should set volatile flags (or synthetic SDL events - better as we don't need to worry about volatile etc), which merged handle_keys_and_video_output thread will detect and initialize Mix*, SDL_Init, ...
  • relatively easy for initialization
  • but we should see how many of SDL_functions get called from pascal mainloop (see ext.txt for list), and how many params they may contain...
• http://lazyfoo.net/SDL_tutorials/lesson33/index.php says I'll also have to call XInitThreads() in my initialization function and link with -lX11
• check that outside of handle_keys_and_video_output thread there is no \b(SDL|gl|Su?lock) function calls
• merge SDL_Delay() and nanosleep() ?