sdl_pad_handler run sdl_instance::get_instance().initialize() outside of main thread

[Kethen]

sdl instance init now has it's own lock, it might be fine to run it outside of main thread

@gdawg can you check if this causes issues on MacOS? #16487

addresses #17227

(lldb) thread list 
Process 8 stopped
* thread #1: tid = 8, 0x00007fcfd94a8a8d libc.so.6`syscall + 29, name = 'rpcs3', stop reason = signal SIGSTOP
  thread #2: tid = 10, 0x00007fcfd94306c2 libc.so.6`__syscall_cancel_arch_end, name = 'Log Writer'
  thread #3: tid = 11, 0x00007fcfd94306c2 libc.so.6`__syscall_cancel_arch_end, name = 'QXcbEventQueue'
  thread #4: tid = 15, 0x00007fcfd94306c2 libc.so.6`__syscall_cancel_arch_end, name = 'QDBusConnection'
  thread #9: tid = 38, 0x00007fcfd94306c2 libc.so.6`__syscall_cancel_arch_end, name = 'libusb_event'
  thread #10: tid = 39, 0x00007fcfd94306c2 libc.so.6`__syscall_cancel_arch_end, name = 'libusb'
  thread #11: tid = 68, 0x00007fcfd94306c2 libc.so.6`__syscall_cancel_arch_end, name = 'QPulseAudioEngi'
  thread #16: tid = 285, 0x00007fcfd94a8a8d libc.so.6`syscall + 29, name = 'Gui Pad Thread'
(lldb) thread select 16
* thread #16, name = 'Gui Pad Thread'
    frame #0: 0x00007fcfd94a8a8d libc.so.6`syscall + 29
libc.so.6`syscall:
->  0x7fcfd94a8a8d <+29>: cmpq   $-0xfff, %rax  ; imm = 0xF001 
    0x7fcfd94a8a93 <+35>: jae    0x7fcfd94a8a96 ; <+38>
    0x7fcfd94a8a95 <+37>: retq   
    0x7fcfd94a8a96 <+38>: movq   0xf634b(%rip), %rcx ; _GLOBAL_OFFSET_TABLE_ + 648
(lldb) bt 
* thread #16, name = 'Gui Pad Thread'
  * frame #0: 0x00007fcfd94a8a8d libc.so.6`syscall + 29
    frame #1: 0x0000000001d12f40 rpcs3`futex(uaddr=0x00007fcedaff72b0, futex_op=128, val=0, timeout=0x0000000000000000, mask=0) at sync.h:78:9
    frame #2: 0x0000000001d12758 rpcs3`atomic_wait_engine::wait(data=0x00007fcedaff72b0, old_value=0, timeout=18446744073709551615, ext=0x0000000000000000) at atomic.cpp:928:7
    frame #3: 0x00000000011661d7 rpcs3`atomic_t<unsigned int, 4ul>::wait(this=0x00007fcedaff72b0, old_value=0, timeout=inf) const requires sizeof (std::remove_cv<T>::type) == 4 at atomic.hpp:1691:3
    frame #4: 0x0000000001c9696d rpcs3`Emulator::BlockingCallFromMainThread(this=0x00000000033bf0c0, func=0x00007fcedaff7438, src_loc=source_location @ 0x00007fcedaff72a8) const at System.cpp:206:11
    frame #5: 0x00000000016247ab rpcs3`sdl_pad_handler::Init(this=0x00007fcde6811840) at sdl_pad_handler.cpp:185:6
    frame #6: 0x000000000158be75 rpcs3`gui_pad_thread::init(this=0x0000000039ff3c50) at gui_pad_thread.cpp:130:20
    frame #7: 0x000000000158de5a rpcs3`gui_pad_thread::run(this=0x0000000039ff3c50) at gui_pad_thread.cpp:258:9
    frame #8: 0x000000000158f898 rpcs3`gui_pad_thread::gui_pad_thread()::$_0::operator()(this=0x0000000035deebc0) const at gui_pad_thread.cpp:45:95
    frame #9: 0x000000000158f875 rpcs3`void std::__invoke_impl<void, gui_pad_thread::gui_pad_thread()::$_0&>((null)=__invoke_other @ 0x00007fcedaff822f, __f=0x0000000035deebc0) at invoke.h:63:14
    frame #10: 0x000000000158f825 rpcs3`std::enable_if<is_invocable_r_v<void, gui_pad_thread::gui_pad_thread()::$_0&>, void>::type std::__invoke_r<void, gui_pad_thread::gui_pad_thread()::$_0&>(__fn=0x0000000035deebc0) at invoke.h:113:2
    frame #11: 0x000000000158f74d rpcs3`std::_Function_handler<void (), gui_pad_thread::gui_pad_thread()::$_0>::_M_invoke(__functor=0x0000000035deebc0) at std_function.h:292:9
    frame #12: 0x0000000000f8198e rpcs3`std::function<void ()>::operator()(this=0x0000000035deebc0) const at std_function.h:593:9
    frame #13: 0x000000000125225a rpcs3`named_thread<std::function<void ()>>::entry_point2(this=0x0000000035deebc0) at Thread.h:488:14
    frame #14: 0x0000000001248bb9 rpcs3`named_thread<std::function<void ()>>::entry_point(_base=0x0000000035deebe0) at Thread.h:469:45
    frame #15: 0x00007fcfc8d6050b
    frame #16: 0x00007fcfd94aacec libc.so.6`__clone3 + 44

[Kethen]

This overlaps a change in #16849

[elad335]

Main thread cannot handle the request? maybe the bug is somewhere else.

[Kethen]

Main thread cannot handle the request? maybe the bug is somewhere else.

Going by the logs, when this happens, quit() has already been called #17227

·! 0:01:27.826821 {Gui Pad Thread} GUI: gui_pad_thread: Pad thread started
·! 0:01:27.826992 {Gui Pad Thread} GUI: gui_pad_thread: Using input configuration: 'Default'
·! 0:01:27.827020 {Gui Pad Thread} Input: Loading pad config (title_id='', config_file='Default', strict=0)
·! 0:01:27.827154 {Gui Pad Thread} Input: Loading input configuration: 'E:/LaunchBox/Emulators/rpcs3-v0.0.17/config/input_configs/global/Default.yml'
·! 0:01:27.829250 {Gui Pad Thread} Input: Loading pad config (title_id='', config_file='Default', strict=0)
·! 0:01:27.829341 {Gui Pad Thread} Input: Loading input configuration: 'E:/LaunchBox/Emulators/rpcs3-v0.0.17/config/input_configs/global/Default.yml'
·! 0:01:27.854258 GUI: Quitting gui application
·! 0:01:27.873162 GUI: Quitting gui application
·! 0:01:27.875189 Media: video_encoder: Stopping video encoder. flush=1
·! 0:01:27.875853 GUI: gui_application: Deleting old game window
·E 0:01:27.896776 SIG: Thread [Gui Pad Thread] is too sleepy. Waiting for it 20857.075us already!

If I understand correctly, main_window::OnEmuStop() was called close to Emulator::Quit(), so a main_window::update_gui_pad_thread() was called causing a m_gui_pad_thread.reset(), and while the thread restarts, sdl_pad_handler::Init() wants the main thread after quit() in m_cb.try_to_quit().

How would you suggest to untangle this?

[elad335]

For my understanding, m_cb.try_to_quit() is a callback, does the main thread actually calls g_fxo->clear() or g_fxo->reset() inside the callback while waiting?

[elad335]

Test with #17230, perhaps it will fix it.

[Megamouse]

It's not supposed to be run outside of the main thread. That's the whole deal

[Megamouse]

Please try the fix from my SDL camera PR

[Kethen]

Added extra information to #17227 (comment) , closing this in favor of #17230 #16849