Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 04 18:24
    cuviper labeled #699
  • Oct 04 03:12
    calebwin opened #699
  • Sep 24 00:33
    bors[bot] closed #695
  • Sep 24 00:33

    bors[bot] on master

    rename `nbody_par` to `nbody_pa… rename `parallel_generations` t… add noop demo and 2 more (compare)

  • Sep 23 23:11

    bors[bot] on staging.tmp

    (compare)

  • Sep 23 23:11

    bors[bot] on staging

    rename `nbody_par` to `nbody_pa… rename `parallel_generations` t… add noop demo and 2 more (compare)

  • Sep 23 23:11

    bors[bot] on staging.tmp

    rename `nbody_par` to `nbody_pa… rename `parallel_generations` t… add noop demo and 2 more (compare)

  • Sep 23 23:11

    bors[bot] on staging.tmp

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

  • Sep 19 23:17
    jClaireCodesStuff synchronize #698
  • Sep 18 23:31
    jClaireCodesStuff opened #698
  • Sep 18 00:47
    jClaireCodesStuff opened #697
  • Sep 15 18:18
    jondot opened #696
  • Sep 14 19:35
    nikomatsakis synchronize #695
  • Sep 14 19:33
    nikomatsakis opened #695
  • Sep 13 14:14
    magnusmanske opened #694
  • Sep 09 23:08
    tiby312 edited #693
  • Sep 09 23:07
    tiby312 edited #693
  • Sep 09 23:04
    tiby312 edited #693
  • Sep 09 23:04
    tiby312 opened #693
  • Sep 06 21:01
    bors[bot] closed #692
Josh Stone
@cuviper
that will definitely block the thread, as this isn't an async library, but other threads should still progress
if you attach a debugger, you should be able to get a backtrace of each thread, and see where they're blocked
Stuart Axelbrooke
@soaxelbrooke
oh god, I'm sorry, it was a shared num_processed variable they were all trying to lock at the same time
threading, how do you even
Josh Stone
@cuviper
whew
rustc will make sure your threading is safe, but not necessarily effective
Stuart Axelbrooke
@soaxelbrooke
you can only protect people from themselves so much :P
Niko Matsakis
@nikomatsakis
So @cuviper I left a comment on #679 -- basically I think that the signature of spawn_future is maybe not quite what I expected
Josh Stone
@cuviper
OK, I hadn't thought of it that way
I guess we would need to implement a Context and Waker then
which is probably doable
Josh Stone
@cuviper
interesting, async-task does look appropriate
Niko Matsakis
@nikomatsakis
@cuviper can't make sync today; first day of school and I want to take "DD" out to ice cream :)
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
Josh Stone
@cuviper
no worries, kids are synchronous
Josh Stone
@cuviper
@nikomatsakis any concerns before I publish 1.2? #686
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