Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Nov 08 19:41
    silwol synchronize #707
  • Nov 08 15:45
    silwol opened #707
  • Nov 08 12:23
    kornelski closed #706
  • Nov 07 23:24
    bors[bot] closed #705
  • Nov 07 23:24

    bors[bot] on master

    Regenerate compat-Cargo.lock Make sure that compat-Cargo.loc… Merge #705 705: Update compat-… (compare)

  • Nov 07 23:13
    kornelski opened #706
  • Nov 07 20:23

    bors[bot] on staging.tmp

    (compare)

  • Nov 07 20:23

    bors[bot] on staging

    Regenerate compat-Cargo.lock Make sure that compat-Cargo.loc… Merge #705 705: Update compat-… (compare)

  • Nov 07 20:23

    bors[bot] on staging.tmp

    Regenerate compat-Cargo.lock Make sure that compat-Cargo.loc… [ci skip][skip ci][skip netlify… (compare)

  • Nov 07 20:23

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • Nov 07 20:09
    matklad opened #705
  • Nov 07 20:04
    bors[bot] closed #704
  • Nov 07 20:04

    bors[bot] on master

    Update crossbeam to avoid multi… Merge #704 704: Update crossbe… (compare)

  • Nov 07 18:29

    bors[bot] on staging.tmp

    (compare)

  • Nov 07 18:29

    bors[bot] on staging

    Update crossbeam to avoid multi… Merge #704 704: Update crossbe… (compare)

  • Nov 07 18:29

    bors[bot] on staging.tmp

    Update crossbeam to avoid multi… [ci skip][skip ci][skip netlify… (compare)

  • Nov 07 18:29

    bors[bot] on staging.tmp

    [ci skip][skip ci][skip netlify] (compare)

  • Nov 07 02:10
    dnaka91 opened #704
  • Nov 06 21:19
    bors[bot] closed #702
  • Nov 06 21:19

    bors[bot] on master

    Adds info about (lack of) objec… Update src/iter/mod.rs Co-Auth… Merge #702 702: Adds info abou… (compare)

Josh Stone
@cuviper
nothing major in there, but a few folks were wanting the updated crossbeam-deque
Emilio Cobos Álvarez
@emilio
Is there any way (even with some runtime overhead) to wait on a thread-pool to shut down? I basically want a sync-drop, to ensure everything is finished by some point, for leak-checking purposes
If there is none, would there be any objection to adding such a switch? @cuviper?
Josh Stone
@cuviper
the global pool doesn't shut down at all
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)
Emilio Cobos Álvarez
@emilio
yeah, I meant a regular ThreadPool instance
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
Josh Stone
@cuviper
or std::sync::Barrier
for TLS, we'd need to actually have joined the threads
Emilio Cobos Álvarez
@emilio
Hmm, barrier doesn't work since I cannot access captured stuff on thread shutdown, and it's not const... Though I guess it could be a lazy_static of some sort
Josh Stone
@cuviper
or Arc-wrapped
Emilio Cobos Álvarez
@emilio
Right, but I cannot access any Arc-wrapped thing in an exit_handler, afaict...
Oh, nvm, it is a closure, I thought it was just a plain fn
Josh Stone
@cuviper
@emilio please file an issue so this doesn't get lost, including some description of the workflow you want
I think we can do it properly in a new API, just need to design that
Emilio Cobos Álvarez
@emilio
Josh Stone
@cuviper
thanks
Emilio Cobos Álvarez
@emilio
np, thank you :)
Josh Stone
@cuviper
@nikomatsakis sync?
Niko Matsakis
@nikomatsakis
@cuviper :wave:
Josh Stone
@cuviper
hey
spawn_future is probably the most interesting thing we have to discuss :)
Niko Matsakis
@nikomatsakis
yeah, probably
sorry, was just skimming a bit
I'm catching up on that PR now
Josh Stone
@cuviper
ISTM that accepting a Future puts us in quite a different position than just returning one
Niko Matsakis
@nikomatsakis
I don't really understand Alex's comment
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
Josh Stone
@cuviper
my loose understanding is that it would be more difficult for a rayon thread in WASM to wait for an async event from the outside environment (JS)
but it's not really clear to me who would get suspended where
async is still a bit magic to me
Niko Matsakis
@nikomatsakis
I guess I don't really understand what the WASM integration looks like
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 calls F::poll, indeed
  • we would give it a Waker that is tied to rayon, I think
  • that job would return NotReady (due to some I/O event), and it would have clone'd our Waker to hold on to it
  • when the I/O event occurs, it would invoke the wake method; this would cause us to add the job back to the (Rayon) thread-pool, at which point we go back to step 1
  • when I did this before, the "unsafety" bit was exactly around this Waker step. If you spawned a future into a scope, I wanted to guarantee that until that future was complete, the scope would not terminate. But the compiler couldn't know that.