4 ms·

The lack of a Leak-style trait is so painful for me that I’d strongly consider switching to a different language that was basically just rust + Leak. (Adding m

by hedora 3y ago

The lack of a Leak-style trait is so painful for me that I’d strongly consider switching to a different language that was basically just rust + Leak. (Adding move and removing pin would be nice to have too.) The problem with not having Leak is that it forces all futures to be ‘static, which effectively disables the borrow checker whenever you cross an async spawn boundary. Arc is the standard solution, but, for multi-threaded code, it can be expensive (though also more predictable, in fairness) than having a GC. The only other solution (which I prefer) is to use an unsafe version of spawn that assumes the future it returns will not be leaked. This certainly breaks the rust promise of supporting safe, zero cost abstractions.

sabageti 3y ago
I have seen many comments like this, and I would like to understand better I feel like I'm missing something. In my daily use case(web api) of async rust we use rarely spawn. What are the use case of intensive spawn usage ? And there is tokio::spawn_local() that doesn't require Send
scottlamb 3y ago
> Arc is the standard solution, but, for multi-threaded code, it can be expensive (though also more predictable, in fairness) than having a GC. Do you have measurements to back that up? I would expect it to be a lot cheaper than GC because GCed language such as Java/Go/etc. GC every heap allocation (and Java in particular doesn't have unboxed objects, so there are a lot of heap allocations!) where Arc<RequestState> would bundle a bunch of things together. That said, I'm not in love with the Arc solution either. It's not just the performance impact. The programming model of scoped concurrency is just much more pleasant. Giving up that and then also having to deal with putting everything into an Arc, and likely also then wrapping it in a MutexLock, even when it should really be one thread at a time dealing with the value in question, just doesn't do anything good for readability and writability of code...
- charcircuit 3y ago
  >because GCed language such as Java/Go/etc. GC every heap allocation GC is not run on every allocation.
  - o11c 3y ago
    They don't run GC, but they subject the extra pointers to GC, whereas good RC languages generally support values. Doing nothing is usually cheaper than doing something. This is more a Java problem than a GC problem; C# supports values just fine, and some heroic JVM-targetting languages also manage it.
    - manwe150 3y ago
      But then mark and sweep also doesn’t have to free the memory (it just does a bulk sweep occasionally), and RC languages do need to free memory used to hold the values later (they have to run expensive compaction and locking steps). So definitely more a Java problem with poor allocation hoisting and reuse than a difference between the RC and mark and sweep implementations of GC.
      - scottlamb 3y ago
        Rust isn't an "RC" language like Java is a "GC" language. It's more flexible than that. Rust has actual unboxed/value structs; it has Box (heap allocation without reference counting); it has Rc (single-thread/no-atomic reference counting); it has Arc (atomic reference counting); it has epoch gc libraries. And, regarding this phrase: > RC languages do need to free memory used to hold the values later It also has arena allocator libraries, so you can group allocations that will be freed at a similar time. You don't need to walk through these to find them all and individually free them. Any Drop impls (destructors/finalizers) get handled via a lifo; then the arena's relatively few, large blocks get freed. I've used this in C++ to squeeze some more performance out of a high-request-rate server. I haven't done it in Rust, but it's the same idea (but safer of course). btw, little confused by this: > [RC languages?] have to run expensive compaction and locking steps Was this meant to refer to GC languages? I've never seen a non-GC language that does compaction (we're talking about the same thing? moving all the heap allocations around to reduce fragmentation?) That's more of a GC language thing that e.g. Java does; it would require the language/runtime to be able to precisely spot pointers and be able to throw in a trap when one it's changing is dereferenced or to entirely stop the world first, and I don't know why you'd take on that complexity and expense if you're not doing GC...
- yencabulator 3y ago
  The reason Arc hurts is that it's global and atomic. Multiple cores competing to inc/dec a shared reference count is pretty much a worst case scenario for modern CPUs. Under modern garbage collection, there's very little need to coordinate across cores, just some barriers every now and then to mark things safe.
  - scottlamb 3y ago
    True, but impact depends on both total core count you're using in the process and what you're doing with Arc. I'm imagining Arc<RequestState> with low concurrency on each RequestState so impact of cache line bouncing should be negligible. If you're talking about Arc<GlobalStuff>, I'd probably use Box::leak instead. There's also a few crates that do epoch gc. I haven't really written super high request rate multicore stuff in Rust, but I have in C++, and there for global-ish occasionally updated config stuff, I used a epoch gc implementation on top of Linux rseq to totally eliminate the effect you're describing.
    - yencabulator 3y ago
      The classic case where Arc hurts and GC really shines is Arc<Config>. Arc makes otherwise read-only activity write.
      - pkolaczk 3y ago
        How many independent things do you need to access the config? A dozen? Then there is a dozen calls to inc the RC at startup, but there is no later cost to read from object behind Arc. So you may read your config a million times and Arc changes nothing. While GC will have to scan the Config structure every time a full GC is needed, so there is an added cost.
        yencabulator 3y ago
        In the trouble scenario, config may change at any time. A getter function has to return a freshly-incremented Arc<Config>, which lives for roughly one request.
jenadine 3y ago
It's probably too complicated to explain in a HN comment, but I don't understand why not having Leak forces futures to be 'static.
- pornel 3y ago
  There's a desire to have futures that run on other threads, but can borrow from temporary locations like stack of their caller. This can't be implemented robustly, because there's no way to enforce the outer scope (the one lending its stack) won't return while the futures are still running. It needs a blocking mechanism that does "wait, your async code hasn't finished yet!", but implementing that via guards and destructors can be bypassed by leaking them. https://without.boats/blog/the-scoped-task-trilemma/ https://without.boats/blog/the-scoped-task-trilemma/ ---- However, running futures on the same thread, with a simple plain .await, does allow them to borrow from the caller's stack safely without restriction. So the first poster in this thread may be doing something unusual, perhaps just over-using multi-threaded spawn() where join_all or streams would suffice.
Matthias247 3y ago
I assume you mean "spawned futures" - because regular Futures obviously don't have to be 'static. You can run as many of them as you want on a single task by using Future combinators like join/select. If this is mostly about scoped async task and the ability to reference data from the parent task, then there also had been a different proposal being discussed which provides the same guarantee: A new Future type (e.g. CompletionFuture), which by represents an async function that needs to be driven to completion. See https://github.com/Matthias247/rfcs/pull/1 https://github.com/Matthias247/rfcs/pull/1 for details. However since this propsal is already 3 years old and hasn't gotten and interest by the Rust async WG, it's probably also not going forward.
deleted 3y ago
[deleted]

by hedora 3y ago

sabageti 3y ago

I have seen many comments like this, and I would like to understand better I feel like I'm missing something. In my daily use case(web api) of async rust we use rarely spawn. What are the use case of intensive spawn usage ? And there is tokio::spawn_local() that doesn't require Send

scottlamb 3y ago

> Arc is the standard solution, but, for multi-threaded code, it can be expensive (though also more predictable, in fairness) than having a GC. Do you have measurements to back that up? I would expect it to be a lot cheaper than GC because GCed language such as Java/Go/etc. GC every heap allocation (and Java in particular doesn't have unboxed objects, so there are a lot of heap allocations!) where Arc<RequestState> would bundle a bunch of things together. That said, I'm not in love with the Arc solution either. It's not just the performance impact. The programming model of scoped concurrency is just much more pleasant. Giving up that and then also having to deal with putting everything into an Arc, and likely also then wrapping it in a MutexLock, even when it should really be one thread at a time dealing with the value in question, just doesn't do anything good for readability and writability of code...

charcircuit 3y ago
>because GCed language such as Java/Go/etc. GC every heap allocation GC is not run on every allocation.
- o11c 3y ago
  They don't run GC, but they subject the extra pointers to GC, whereas good RC languages generally support values. Doing nothing is usually cheaper than doing something. This is more a Java problem than a GC problem; C# supports values just fine, and some heroic JVM-targetting languages also manage it.
  - manwe150 3y ago
    But then mark and sweep also doesn’t have to free the memory (it just does a bulk sweep occasionally), and RC languages do need to free memory used to hold the values later (they have to run expensive compaction and locking steps). So definitely more a Java problem with poor allocation hoisting and reuse than a difference between the RC and mark and sweep implementations of GC.
    - scottlamb 3y ago
      Rust isn't an "RC" language like Java is a "GC" language. It's more flexible than that. Rust has actual unboxed/value structs; it has Box (heap allocation without reference counting); it has Rc (single-thread/no-atomic reference counting); it has Arc (atomic reference counting); it has epoch gc libraries. And, regarding this phrase: > RC languages do need to free memory used to hold the values later It also has arena allocator libraries, so you can group allocations that will be freed at a similar time. You don't need to walk through these to find them all and individually free them. Any Drop impls (destructors/finalizers) get handled via a lifo; then the arena's relatively few, large blocks get freed. I've used this in C++ to squeeze some more performance out of a high-request-rate server. I haven't done it in Rust, but it's the same idea (but safer of course). btw, little confused by this: > [RC languages?] have to run expensive compaction and locking steps Was this meant to refer to GC languages? I've never seen a non-GC language that does compaction (we're talking about the same thing? moving all the heap allocations around to reduce fragmentation?) That's more of a GC language thing that e.g. Java does; it would require the language/runtime to be able to precisely spot pointers and be able to throw in a trap when one it's changing is dereferenced or to entirely stop the world first, and I don't know why you'd take on that complexity and expense if you're not doing GC...
yencabulator 3y ago
The reason Arc hurts is that it's global and atomic. Multiple cores competing to inc/dec a shared reference count is pretty much a worst case scenario for modern CPUs. Under modern garbage collection, there's very little need to coordinate across cores, just some barriers every now and then to mark things safe.
- scottlamb 3y ago
  True, but impact depends on both total core count you're using in the process and what you're doing with Arc. I'm imagining Arc<RequestState> with low concurrency on each RequestState so impact of cache line bouncing should be negligible. If you're talking about Arc<GlobalStuff>, I'd probably use Box::leak instead. There's also a few crates that do epoch gc. I haven't really written super high request rate multicore stuff in Rust, but I have in C++, and there for global-ish occasionally updated config stuff, I used a epoch gc implementation on top of Linux rseq to totally eliminate the effect you're describing.
  - yencabulator 3y ago
    The classic case where Arc hurts and GC really shines is Arc<Config>. Arc makes otherwise read-only activity write.
    - pkolaczk 3y ago
      How many independent things do you need to access the config? A dozen? Then there is a dozen calls to inc the RC at startup, but there is no later cost to read from object behind Arc. So you may read your config a million times and Arc changes nothing. While GC will have to scan the Config structure every time a full GC is needed, so there is an added cost.
      - yencabulator 3y ago
        In the trouble scenario, config may change at any time. A getter function has to return a freshly-incremented Arc<Config>, which lives for roughly one request.

jenadine 3y ago

It's probably too complicated to explain in a HN comment, but I don't understand why not having Leak forces futures to be 'static.

pornel 3y ago
There's a desire to have futures that run on other threads, but can borrow from temporary locations like stack of their caller. This can't be implemented robustly, because there's no way to enforce the outer scope (the one lending its stack) won't return while the futures are still running. It needs a blocking mechanism that does "wait, your async code hasn't finished yet!", but implementing that via guards and destructors can be bypassed by leaking them. https://without.boats/blog/the-scoped-task-trilemma/ https://without.boats/blog/the-scoped-task-trilemma/ ---- However, running futures on the same thread, with a simple plain .await, does allow them to borrow from the caller's stack safely without restriction. So the first poster in this thread may be doing something unusual, perhaps just over-using multi-threaded spawn() where join_all or streams would suffice.

Matthias247 3y ago

I assume you mean "spawned futures" - because regular Futures obviously don't have to be 'static. You can run as many of them as you want on a single task by using Future combinators like join/select. If this is mostly about scoped async task and the ability to reference data from the parent task, then there also had been a different proposal being discussed which provides the same guarantee: A new Future type (e.g. CompletionFuture), which by represents an async function that needs to be driven to completion. See https://github.com/Matthias247/rfcs/pull/1 https://github.com/Matthias247/rfcs/pull/1 for details. However since this propsal is already 3 years old and hasn't gotten and interest by the Rust async WG, it's probably also not going forward.

deleted 3y ago

[deleted]