I try to finish a program with a lot of threads (eg 6). In particular, it call libc exit(0) from one of them.
Then seems that it start to free memory , and one of threads accidentally receive timer event, and try to access its own memory - and fail because it already became inaccessible.
Unfortunately I do not have normal control over it (this is just a behavior of golang “hello world” program!)
Can I forcible cancel all timers/signals inside program threads and stop all activities to avoid such problems? Better without races ;)
Sincerely, Alexander
Hi Alexander,
On Mon, Jan 06, 2020 at 13:19:15 CET, Alexander Tormasov via users wrote:
I try to finish a program with a lot of threads (eg 6). In particular, it call libc exit(0) from one of them.
Then seems that it start to free memory , and one of threads accidentally receive timer event, and try to access its own memory - and fail because it already became inaccessible.
Unfortunately I do not have normal control over it (this is just a behavior of golang “hello world” program!)
Can I forcible cancel all timers/signals inside program threads and stop all activities to avoid such problems? Better without races ;)
Unfortunately, you're stumbling over an unfinished feature of our current libc runtime - complete support for multithreading. In your case, I expect the first thread calling exit() just executes all destructors and atexit handlers, which leaves the component in an almost terminated state.
If you like to improve this by force-stopping all other threads before finalizing the component, you could look into the libc implementation and implement a kind of termination broadcast and signal handler for this purpose. This mechanism should pthread_join all other threads and therefore be implemented in the main entrypoint. Sounds complex? It really is! For example, the FreeBSD libc has support for thread-local dtors (which is a very good idea because of __thread/_Thread_local/thread_local in C/C++) that must be executed if a pthread terminates.
Greets