The Latest Progress On Rust For The Linux Kernel

[mdedetrich]

Not being used in the compiler does not mean its not part of the borrow checker design of rust.

No it really does or you are using the word "design" so liberally that it loses all meaning. The borrow checker (according to both rustc developers and the community) is a phase in the compiler (see https://rustc-dev-guide.rust-lang.or...r-borrow-check) that tracks memory management at compile time.

RefCell is implemented in the stdlib and actually works completely differently to the borrow checker (as stated before its a struct that contains the value along with the either a counter or a special constant)

They have completely different designs, the only interaction that RefCel has with the borrow checker is via the type system so that your Rust program can actually compile when using RefCel, saying this is part of the same design as the borrow checker is such a stretch that honestly it looks like you are trying to dig yourself out of a hole.

[mdedetrich]

Async programing , you can have multiple tasks running on a single thread with tokio with can make you program not deterministic because it relies on external events to be done and can jump around the program in different execution points.

This is actually called the reactor pattern or an event driven loop and it actually can be completely deterministic, for example its the exact same thing Javascript does with callbacks and in Javascript its deterministic (no need for refcells, locks, atomic operations etc etc). In javascript all of these operations are ordered but it only works because Javascript is single threaded by design.

As pointed about before with concurrency and parallelism, if you are being concurrent but only have a single core/thread then in reality its not concurrent (i.e. you are only executing one task at a time) but as observed in your program/application/library you see it as multiple tasks happening at once.

Of course this all depends on implementation, not sure how GTK handle's events or what the architecture is.

[oiaohm]

RefCell is implemented in the stdlib and actually works completely differently to the borrow checker (as stated before its a struct that contains the value along with the either a counter or a special constant)

https://doc.rust-lang.org/std/cell/struct.RefCell.html

A mutable memory location with dynamically checked borrow rules

mdedetrich please stop ignoring the rust documentation. RefCell is in fact documented as part of rust total borrow checker design and this is reflected in its documented description. How the special constant of RefCell works is documented in the rust borrow checker design.

This is a problem mdedetrich you are pushing rust with in fact understanding rust borrow checker design that well at all. I mentioned oxide update this is important change to make rust less limited by its borrow checker leading to the introduction of these dynamic borrow checker bits that the compiler itself identifies to allow items that cannot be solved statically.

The original design of rust had no dynamic borrow checker. Since the oxide change there has been limited dynamic borrow checker that the compiler identifies and allows code that it cannot statically solve.

The rust static borrow checker can detect what areas are dynamically borrow checked then cross fingers that the programmer got that area of code right. If you did not get that area of code right this could be a instant splat/panic.

Yes there is a horrible weakness that you use RefCell instead of Cell and code that would have prior thrown a build error due to static borrow checking now no longer does but instead throws runtime error. This is a problem the Linux kernel recent changes for anti buffer overflow for C code does not down grade quality of static checking because a dynamic checker is going to be used.

Really rust does need to sort out its static borrow checker so that it still gives at least warning in dynamically checked sections if something looks stupid.

[mdedetrich]

https://doc.rust-lang.org/std/cell/struct.RefCell.html

A mutable memory location with dynamically checked borrow rules

mdedetrich please stop ignoring the rust documentation. RefCell is in fact documented as part of rust total borrow checker design and this is reflected in its documented description. How the special constant of RefCell works is documented in the rust borrow checker design.

No its not, check the source code of the Rustc compiler please, I already linked the actual compiler documentation previously.

All the documentation for RefCell is saying is that it can check borrow variants at runtime which no one is debating. You can even write your own abstractions to check borrow variants at runtime yourself, that doesn't mean its part of the borrow checker.

What you are saying is making zero sense, which historically isn't a first coming from you.

[ultimA]

Originally posted by cl333r View Post
Not to me, I don't want my app to crash at random points at random times at runtime because the borrow checker saw aliased mutability or something and judges like: found a black person, he must be in prison unless proven innocent - in the name of security.
Imagine your app crashing at runtime in a plane that is landing or other such scenarios like life support in a hospital.

You should try Rust one day instead of talking BS. The borrow checker is static and works at compile time, it doesn't do anything at runtime (and is not linked into the binary)

Not BS. cl333r is only wrong about the borrow checker being a good example. While it is not the borrow checker, Rust (and its standard library) does do more runtime checks that can unexpectedly terminate your program.

[oleid]

Please note I did not say that runtime borrow checker bits were not opt in. But the fact they are opt in they are something you have to be aware of when comparing benchmark results.


Not being used in the compiler does not mean its not part of the borrow checker design of rust.

The current borrow checker design of Rust is Polonius, not Oxide. Oxide is currently purely an academic research language. Which might lead to ideas, which might get integrated to rust, eventually. I'm not really sure why you keep bringing it up.

Interesting enough it appears rust compiler developers have stalled on implementing oxide completely so that people can keep on claiming that rust does not have a dynamic borrow checker or if people use the dynamic borrow checker parts they had to opt in.

They never started. And currently Polonius is not even fully integrated (http://smallcultfollowing.com/babyst...-back-on-2020/)

[oleid]

While it is not the borrow checker, Rust does do more runtime checks that can unexpectedly terminate your program.

Indeed, most notably failure of allocation. Luckily, the discussions on the kernel mailing list lead to a greater awareness of those issues and they are being addressed.
For the kernel inclusion, this is not a big deal, however, since they are going to provide their own API anyway. It is more an issue of the standard library, which is not going to be used in the kernel.

[jacob]

Originally posted by cl333r View Post
Not to me, I don't want my app to crash at random points at random times at runtime because the borrow checker saw aliased mutability or something and judges like: found a black person, he must be in prison unless proven innocent - in the name of security.
Imagine your app crashing at runtime in a plane that is landing or other such scenarios like life support in a hospital.



Not BS. cl333r is only wrong about the borrow checker being a good example. While it is not the borrow checker, Rust does do more runtime checks that can unexpectedly terminate your program.

In fact it does not really, only RefCell when not using try_borrow() and bounds checks in cases when the compiler can't prove statically that the index is correct. The latter happens (or SHOULD happen) in any language including C, except that it would be explicitly written by the coder, and RefCell has been discussed to death here. But that's pretty much it (except the likes of .expect(), .ok() etc, which are the Rust equivalent of ignoring return values or errno in C).

[oleid]

Not to me, I don't want my app to crash at random points at random times at runtime because the borrow checker saw aliased mutability or something and judges like

Then don't use RefCells in your code, it is as simple as that.

[ultimA]

Then don't use RefCells in your code, it is as simple as that.

I said nothing about RefCells...

In fact it does not really, only RefCell when not using try_borrow() and bounds checks in cases when the compiler can't prove statically that the index is correct. The latter happens (or SHOULD happen) in any language including C, except that it would be explicitly written by the coder, and RefCell has been discussed to death here. But that's pretty much it (except the likes of .expect(), .ok() etc, which are the Rust equivalent of ignoring return values or errno in C).

I wasn't talking about memory management only, you both are still stuck in your discussion with cl333r. I meant in Rust in general. Allocation failures are a good example as oleid said a little bit earlier, but there are also bounds checking and arithmetic (under-/overflow, downcasting) checks. I know these can be disabled, but then they also don't provide their advantages anymore.