4

I want to use a thread local variable of type Option<usize> in a Rust library. How many bytes will this use per thread for crates that have a dependency on my library? I'm interested in Rust 1.39 and targeting Linux for three processors: amd64, x86 and arm32.

Frank C.
  • 7,758
  • 4
  • 35
  • 45
Rüdiger Klaehn
  • 12,445
  • 3
  • 41
  • 57
  • All Linux. If you look at the code you will see that there is a "fast" version and an "os dependent" version. So it is not at all clear that rust uses the OS version, and from the godbolt compiler explorer link I posted in the "bad" question it is clear that there is no call into an OS api at least at highest optimization level... – Rüdiger Klaehn Nov 19 '19 at 20:52
  • what make you think it will use more bytes that the real type ? – Stargateur Nov 19 '19 at 20:53
  • There are tons of different ways to implement thread local storage. I just want to know the details so I know how much of a burden it is to users of the library. – Rüdiger Klaehn Nov 19 '19 at 20:56
  • guess this kind of "detail" is compiler specific and are subject to change at anytime. – Stargateur Nov 19 '19 at 21:11
  • 1
    Rust is not java. The target audience of rust needs to know the details. A feature where the resource usage can change at any time is not typical for rust. – Rüdiger Klaehn Nov 19 '19 at 21:15
  • No, this is wrong, even in C thread local variable are implemented behaviour. I can't explain the real difference between Rust and java in a comment. – Stargateur Nov 19 '19 at 21:40
  • What I meant is that in java you often get answers like: the runtime will take care of it, whereas in rust you usually know exactly e.g. how the bytes are layed out in memory. So fine, it can change at any time, but how is it *currently* implemented? – Rüdiger Klaehn Nov 19 '19 at 22:26
  • @Stargateur good thing that we all are sane in here and only use one and only compiler, rustc... Even then, it's not very relevant, because sizes won't ever change unless we are talking about very specific things, such as usize and "hacky" (I personally know none for anything) implementations of things for embedded programming. –  Nov 21 '19 at 14:13

0 Answers0