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 :)
sorry, was just skimming a bit
I'm catching up on that PR now
I guess I would assume he didn't read the PR very closely
anyway, I agree it is rather different
which is why I was pressing for it :)
as it seems significantly more enabling
but it's not really clear to me who would get suspended where
async is still a bit magic to me
if we ignore that for a second,
you wrote this on the PR
I guess if the async work leading up to our part isn't ready, we'd just return NotReady too and let some outer executor deal with it?
I believe what would happen is roughly like this:
- when you invoke
spawn_future(F: impl Future), we would schedule a job that callsF::poll, indeed
- we would give it a
Wakerthat is tied to rayon, I think
- that job would return
NotReady(due to some I/O event), and it would have clone'd ourWakerto hold on to it
- when the I/O event occurs, it would invoke the
wakemethod; this would cause us to add the job back to the (Rayon) thread-pool, at which point we go back to step 1