The uFMOD_PlaySong() creates 3 threads in my prog, but uFMOD_StopSong() only removes 2, leaving one. This makes it where my process remains even after returning from the entry function.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello! Thanks for the feedback. Actually, it's not a bug but normal Windows behaviour.
To correctly stop a program you need to call ExitProcess(). Just returning from the entry point only works in very simple cases, it doesn't work most of the time in multithreaded apps (unless you don't use any COM, WINMM and so on). The 3rd thread you mentioned should be the WINMM engine thread. uFMOD doesn't have conrol over it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I guess you mean "normal Windows behaviour" in the sense that lots of programs do it. The problem with calling ExitProcess is described on MSDN in the documentation for the ExitThread function:
"ExitThread is the preferred method of exiting a thread in C code. However, in C++ code, the thread is exited before any destructors can be called or any other automatic cleanup can be performed. Therefore, in C++ code, you should return from your thread function."
The solution here is to enter a sub-procedure immediately after reaching your entry point. From here you can return in the *normal* way, invoking local object destructors, before calling ExitProcess to satisfy uFMOD.
This will still leave static globals initialized. Perhaps the runtime exit() function would work here.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The uFMOD_PlaySong() creates 3 threads in my prog, but uFMOD_StopSong() only removes 2, leaving one. This makes it where my process remains even after returning from the entry function.
Hello! Thanks for the feedback. Actually, it's not a bug but normal Windows behaviour.
To correctly stop a program you need to call ExitProcess(). Just returning from the entry point only works in very simple cases, it doesn't work most of the time in multithreaded apps (unless you don't use any COM, WINMM and so on). The 3rd thread you mentioned should be the WINMM engine thread. uFMOD doesn't have conrol over it.
I guess you mean "normal Windows behaviour" in the sense that lots of programs do it. The problem with calling ExitProcess is described on MSDN in the documentation for the ExitThread function:
"ExitThread is the preferred method of exiting a thread in C code. However, in C++ code, the thread is exited before any destructors can be called or any other automatic cleanup can be performed. Therefore, in C++ code, you should return from your thread function."
The solution here is to enter a sub-procedure immediately after reaching your entry point. From here you can return in the *normal* way, invoking local object destructors, before calling ExitProcess to satisfy uFMOD.
This will still leave static globals initialized. Perhaps the runtime exit() function would work here.