weird
if you attach a debugger, you should be able to get a backtrace of each thread, and see where they're blocked
threading, how do you even
rustc will make sure your threading is safe, but not necessarily effective
I guess we would need to implement a Context and Waker then
which is probably doable
but after digging a bit more into async-task, it did seem like a good fit for what we need -- haven't checked if there are more comments on #679 yet though
nothing major in there, but a few folks were wanting the updated crossbeam-deque
If there is none, would there be any objection to adding such a switch? @cuviper?
for other
ThreadPool instances, it should be possible
I think we already do this with some internal APIs for tests
I tinkered with a public API at some point, if I can find that branch
(feels like I say that a lot -- need to get better at publishing such things)
I guess I can and add an atomic counter to
thread_shutdown or something... Not the prettiest thouh
*though
exit_handler, I mean :)
Given I know the expected number of threads... still not amazing, and I think not enough to fully guarantee that all TLS destructors have run
for TLS, we'd need to actually have joined the threads
Oh, nvm, it is a closure, I thought it was just a plain fn
I think we can do it properly in a new API, just need to design that
spawn_future is probably the most interesting thing we have to discuss :)