Threading model of the libretro API

Libretro Cores
#1

Hi!

I have an occasional bug in my core, a segfault when I reset the emulator. I tried to analyze this bug, and my current explanation is that it is triggered when retro_reset() is called when retro_run() is also running. My expectations were that all the retro_* functions were mutually exclusive and/or called in the same thread, but now I have doubts about that. So my question is: what is the threading model of the libretro API?

Regards Thomas

#2

I asked bparker about it on discord and he said:

 [8:10 AM] bparker: run ASAN
 [8:10 AM] bparker: then TSAN
 [8:10 AM] bparker: come back if still broke
 [8:10 AM] bparker: lol

The long and short is really that libretro doesn’t have a threading model of its own. That can be a drag for cases like this, but if your core has a weird threading thing, you don’t have to then reconcile it with libretro.

#3

Thank you for your answer. I didn’t run ASAN/TSAN, I will try to do it. My analysis was based on the results of valgrind (which is the same kind of tool then ASAN/TSAN).

#4

looking at the source code to retroarch first by using:

grep -nr retro_reset

then:

grep -nr core_reset

and then:

grep -nr CMD_EVENT_RESET

afaict (and if we’re ignoring netplay, achievement, and run ahead code) retro_reset is only invoked in a couple spots, namely from retroarch.c, menu/cbs/menu_cbs_ok.c, ui/drivers/ui_cocoa.m, and ui/drivers/ui_win32.c. the call from retroarch.c, which is triggered by pressing the key assigned to reset in retroarch, does not overlap retro_run. for the other invocations i don’t know if it’s possible or not, but perhaps this will be enough for you to figure out where your problem might be.

1 Like
#5

Thanks very much for your help.