how drop rayon whren it in a dylib and dylib should be droped?
simline opened this issue · comments
load dylib in fedora using libloading, but after calling the function in dylib when there's some rayon work, dylib is not drop correctly.
When I removed all the rayon code, libloading drop dylib works fine.
What should I do?
lsof | grep 'MyLibName' always got 8(4c8t) instances
What target are you running on? (e.g. x86_64-unknown-linux-gnu)
What target are you running on? (e.g.
x86_64-unknown-linux-gnu)
rustup default：stable-x86_64-unknown-linux-gnu (default)
OK, so with all *-linux-gnu targets, an important caveat is that glibc's dlclose doesn't do anything when there's a pending TLS destructor from that library. I don't think any of rayon's own thread_local! variables have destructors, but crossbeam-epoch does, and even the standard library has ThreadInfo that must be dropped.
I'm not sure, but it might work if you guarantee all rayon threads have completely exited before you try to unload. You can't do that at all with the global pool, and an explicit ThreadPool handle doesn't synchronize its threads on exit either (#688). I think even my suggestion there to use build_scoped might not be good enough given rust-lang/rust#116237, but a stronger version of that could collect and join all the thread handles.
But even with all that, it's possible that some code might have registered TLS destructors in non-rayon threads too, and I have no idea what could be done about that.
but a stronger version of that could collect and
joinall the thread handles.
Here's a prototype of that: master...cuviper:rayon:join-scoped