[pre-RFC] Remove static mut

[Ericson2314]

What are you doing about the array-pointer inconsistency? Does *mut [T] Work? Otherwise sounds excellent. Hope to see this, and a better global initialization story, soon. (Finally the static locks can contain a value!)

[eddyb]

Ah, yes, I mentioned that for a reason and then proceeded to forget about it when I realized I have no immediate solution. &racy_cell!([a, b, c]) as &RacyCell<[T]> would work if it weren’t for the fact that you can’t take a reference to a value with interior mutability. We’d have to either lift that restriction inside static (unlike const, it can only mean one thing), or allow static to be unsized (in this case, RacyCell<[T]>), which is okay since it’s always an lvalue.

[Ericson2314]

if it weren’t for the fact that you can’t take a reference to a value with interior mutability

What do you mean?

or allow static to be unsized

Hmm, so the static is still defined fix size, and thus no extra indirection? I like this–abstraction for privacy rather than dynamism (like opaque type synonym I also want). Reminds me how I wanted to hide dimensions in https://github.com/RustOS-Fork-Holding-Ground/RustOS/blob/master/src/arch/x86/vga.rs

[Ericson2314]

Also, do we need RacyCell, or could accessing statics that don’t impl Sync just be unsafe?

[eddyb]

I mean that &UnsafeCell { value: () } for example is not valid inside const, static or static mut, only inside functions.

[eddyb]

Well, the interface is already unsafe even with just UnsafeCell - actually, in my original version I had just UnsafeCell, but it was since made non-Sync and for a while there was a RacyCell (which seems to have been removed already) as a Sync wrapper around UnsafeCell, so I replicated that. There’s room for improvement here, I’m sure.

[Ericson2314]

Oh, in the static/const itself, duh.

Oh yeah good point, I was thinking taking a reference to the UnsafeCell itself would also be unsafe, but that is not necessary. Maybe the Sync requirement can just be dropped altogether? Implementing Sync doesn’t make the encapsulation of an unsafe cell any safer, just declares ones confidence in that abstraction. (There could probably be a lint about missing unsafe impl Syncs, in general, but that is another discussion.)

[eddyb]

The requirement is there because of types like Cell which aren’t safe in a static, and missing Sync is the only difference between those and types which can be safely shared between threads.

[Ericson2314]

Hmm, that’s awkward. Cell, RefCell, and Rc are all weird like that. I wonder if something like the ST monad could keep them in check.

[nikomatsakis]

Essentially the only legit use case for static mut that I’m aware of is modeling an extern C global. I suspect this could be done by just using an UnsafeCell on the Rust side – the memory layout is compatible after all – but it’s less direct.

[nikomatsakis]

eddyb points out that I’m sort of conflating “extern” globals and globals declared in Rust, which is true. I think I’m fine with removing static mut overall.

[dhardy]

Links for those like me struggling to follow:

• http://doc.rust-lang.org/reference.html#static-items
• http://doc.rust-lang.org/std/cell/struct.UnsafeCell.html

One thing to note: UnsafeCell says it should only be used with mut statics to avoid trying to mutate invariant memory. How instead then will a static item be placed in read-write memory?

From my point of view, “mutable statics” are weird enough that I would want to hide them behind some access function anyway, so the main consequence of this proposal would be to make ugly code slightly uglier.

[eddyb]

Oh wow, those docs are very wrong. If a static has interior mutability (i.e. it contains UnsafeCell), it will be placed in read-write memory (automatically). The only restriction is that the type is Sync (hence the use of RacyCell).

[tbu]

FIx is in the queue, though:

Remove comment about `UnsafeCell`s and `static`

[krzysz00]

Just to clarify (as someone who just found this discussion) would this horrific mess still work with the new system?

(lidt2() is

lidt idtDesc
ret

which is why idtDesc is public)

[eddyb]

You can use inline assembly to handle that - and then you don’t need any globals at all.

If you want to keep using globals (or you have other places where you need them), an “interrupts disabled” lock around a static should also work and it can be a newtype around the type (which would bave to contain Cell or RefCell I guess - but the former is 0 overhead).

However, this pre-RFC needs to be updated to make use of const fn and change from “remove” to “deprecate”, sadly, as it missed the mark (unless the core team thinks otherwise). And in my absence, someone else would have to take over for it to stand a chance (cc @nikomatsakis).

[krzysz00]

I can see how the cell types will be sufficient for almost all of my use cases ( if I roll my own Mutex), especially if the proposed -Z abort-on-panic is implemented.

However, I’m still uncertain about how I would replace #[no_mangle] public static mut idtDesc with a cell type. The problem with the interrupt table descriptor is that the instruction for loading it has one form, which takes a fixed memory address. This means that the linker has to know where idtDesc will be at link time in order to generate the necessary code.

[comex]

Can’t you just use the address of the cell, since the memory layout is compatible?

[krzysz00]

You’re right, that actually does work!

I was pleasantly surprised that my Notex type (it has a mutex-like API, but no thread safety) had no memory overhead. (current state of the IDT code for reference).

Well, there goes one use case for static mut, assuming the compiler stays sufficiently smart.

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.