3

I'm sharing a variable been threads in a Rust program. This variable is only ever read from in these threads, and never written to elsewhere following being passed to the threads (it is only written to before the threads are spawned). The variable should live as long as the program is running; if it no longer lives the entire program's functionality will fall apart. As for the program itself, it runs indefinitely. As for the threads, their spawning is facilitated by Tokio's tokio::main macro. I do not configure the thread spawning in any way; the default behaviour of the macro is used.

I found two solutions to this:

  1. Put the variable in a Box and then run leak() on it and give it a static lifetime.
  2. Put the variable in an Arc, and give each thread a clone of the Arc.

Initially I thought using an Arc would be preferable as leaking sounded bad in my head, however now that I think about it I imagine Arc would have unnecessary overhead as from what I understand it needs to do more than a variable leaked from a Box.

Is this the case? Would using an Arc here introduce unnecessary overhead? And, considering my situation, is there any reason I might want to use an Arc? I'm looking to introduce as little overhead as possible as I want minimal latency for operations.

Newbyte
  • 2,421
  • 5
  • 22
  • 45
  • 1
    [Creating a global singleton](https://stackoverflow.com/questions/27791532/how-do-i-create-a-global-mutable-singleton) would probably be better than any of those two approaches, but I wouldn't say that there is a _right_ answer to this. – E_net4 Jul 02 '20 at 09:59
  • 1
    @E_net4flagsheat Okay, fair enough, but even then I think the questions at the end should have objective answers, even if the overarching topic does not. That said, in which way would a global singleton be better? – Newbyte Jul 02 '20 at 10:03
  • There aren't enough details to outline which one would be better. – E_net4 Jul 02 '20 at 10:05
  • 1
    @E_net4flagsheat What information might help clarify? – Newbyte Jul 02 '20 at 10:15
  • Did you also consider 3. Use scoped threads to pass an ordinary (non-`'static`) reference? Or does your use case not permit that? – trent Jul 02 '20 at 11:23
  • @trentcl The thread spawning is facilitated by Tokio via [the `tokio::main` macro](https://tokio-rs.github.io/tokio/doc/tokio_macros/attr.main.html), so I don't think this is an option in this case. Thank you for the suggestion though. Maybe this is worth adding to the question. – Newbyte Jul 02 '20 at 11:47
  • It feels like you have all the pieces here, to the point that an answer would be mostly just restating the content of the question: Using `Arc` introduces a small amount of runtime overhead when cloning the reference, but using `Box::leak` instead gives up the ability to destroy the value when you're done. Answering questions of the form "What *should* I do?" generally requires (1) a lot more detail about your use case and (2) a definition of "good" so that we can evaluate the relative quality of solutions. Architecture questions with insufficient detail are often closed as opinion-based. – trent Jul 02 '20 at 12:23
  • Details might be stuff like: what are the hard constraints of your design? What metrics are you using to decide the relative goodness of solutions, and what priority do you place on them? Does the reference get copied a lot once passed to a thread? How many threads are there? Does the program end immediately as soon as the value is no longer needed, or is there more work to be done? How big is the value? It can be hard to ask good questions about software architecture because good architecture heavily depends on real-world objectives and constraints, of which there may be arbitrarily many. – trent Jul 02 '20 at 12:45
  • @trentcl Thank you for the elaborate explanation. – Newbyte Jul 02 '20 at 15:33

0 Answers0