aturon

9 ms·

31.
by aturon 11y ago
Yes. In practice this is extremely unlikely for correct lock-free structures. But you can also protect against it by releasing the epoch on every iteration of the retry loop, rather than just at the outset. (This may be a good idea for ot
32.
by aturon 11y ago
Not toooo much, but I will say that feeling inspired by the typesetting helped keep my motivation up for all 299 pages...
33.
by aturon 11y ago
They are very similar; I think of the epoch scheme as a particular way of doing RCU that does not impose the need to find quiescent states yourself (RCU can be employed in userspace as well if your application can provide quiescent states i
34.
by aturon 11y ago
After discussing idioms with a few others on the Rust team, I've pushed this refactoring, bringing the example down to a single use of `unsafe`. Feels much cleaner, and draws attention to `unlinked` as the source of unsafety here.
35.
by aturon 11y ago
Oh, it's also worth saying that only the `unlinked` method really has to be unsafe, since it's the root of any unsafety with this API. I chose to make the `_shared` methods unsafe as well because they present one of the ways tha
36.
by aturon 11y ago
As others have said, in a low-level setting like this it would be very difficult to ensure total safety, which depends on complex data structure invariants. That said, Rust is able to eliminate some sources of unsafety here -- in particul
37.
Lock freedom without garbage collection in Rust(aturon.github.io)
234 points by aturon 11y ago|90 comments
38.
by aturon 11y ago
There's an O'Reilly book in the works: http://www.amazon.com/Programming-Rust-Jim-Blandy/dp/1491927... And The Rust Programming Language ( https://doc.rust-lang.org/book ) is on its way to
39.
by aturon 11y ago
I definitely agree, this is a pain point in Rust today, and it's something the core team would like to address. You might glance at the thread here for some of the tradeoffs: https://internals.rust-lang.org/t/impli
40.
by aturon 11y ago
Not yet, but Nick Cameron (@nrc) has been holding talks with many IDE makers and plans to launch a "Rust IDE initiative" very soon.
41.
Rust in 2016(blog.rust-lang.org)
371 points by aturon 11y ago|149 comments
42.
by aturon 11y ago
Rust's basic guarantee has been, and continues to be: unless code uses `unsafe`, it is guaranteeed to be memory safe. The issue under discussion doesn't change that -- it's largely about what such `unsafe` code is allowed t
43.
by aturon 11y ago
Please see my comment below ( https://news.ycombinator.com/item?id=9447938 ) -- a key point is that, as always, you have to write `unsafe` to get memory unsafety in Rust, period . This is Rust's core guarantee. The issu
44.
by aturon 11y ago
Please see my comment below ( https://news.ycombinator.com/item?id=9447938 ). If this were a problem for Rust's basic memory safety guarantees, we'd certainly consider delaying release. There are also ways to pursue
45.
by aturon 11y ago
Please see my comment below ( https://news.ycombinator.com/item?id=9447938 ). There is no risk to Rust's basic safety guarantees here, and there are several ways forward (including introducing things like `Leak` backward
46.
by aturon 11y ago
I want to clarify a couple of points: Most important, this API problem does not break Rust's basic safety guarantee . That is, you must write unsafe code to violate memory safety. If Rust's basic memory safety guarantee were a
47.
by aturon 12y ago
To be clear, the basic concept of scoped threads is fine, and this unsoundness was a result of explicitly `unsafe` code. The specific API chosen, however, used RAII guards to "guarantee" that the parent thread joined on the child
48.
by aturon 12y ago
What's going on here is a bit of shorthand. If you don't use the shorthand, the signature looks like: fn access<'a, T: Send>(guard: &'a mut MutexGuard<T>) -> &'a mut T; This says that
49.
by aturon 12y ago
The key is that the MutexGuard is responsible for unlocking (and it does so automatically on destruction). That way, you're tying the scope for the &mut reference to the scope in which the lock is actually held.
50.
by aturon 12y ago
That's not quite right. In the non-move case, the capture is inferred per upvar . See my other comment for details ( https://news.ycombinator.com/item?id=9047766 )
51.
by aturon 12y ago
> The way variables are captured from the environment into the closure is controlled by the "move" keyword. If the "move" keyword precedes a closure expression, then variables from the environment are moved into the c
52.
by aturon 12y ago
> That said, I'm not sure what the exact reason was for choosing the syntax, as that was before my time. I think the reason is just that it's very concise, and lightweight closure syntax makes things like `Option::map` feel lik
53.
by aturon 12y ago
There's a core team ( https://github.com/rust-lang/rust/wiki/Note-core-team ) responsible for final decisions on the direction of the language and libraries. Proposed changes go through a public RFC proces
54.
by aturon 12y ago
There has been a lot of work on `std`, but it's largely been consistency, cleanup and cutting APIs down -- though the recent path and IO reforms are more substantial, which is why we decided to put out another alpha before finalizing t
55.
by aturon 12y ago
The renaming to "old_io" is purely to make updating code clearer easier -- it does not indicate a massive redesign. The final API will actually be quite similar to the existing std::io in most respects. It fixes a few longstandi
56.
by aturon 12y ago
This is a very old post, but you can encode many uses of typestate pretty easily: http://pcwalton.github.io/blog/2012/12/26/typestate-is-dead/ It'd be great for someone to write a more up-to-da
57.
by aturon 12y ago
I completely agree that a strong standard library is essential, and we've been working very hard over the last months to set explicit conventions, revamp APIs, and generally get Rust's standard library into a 1.0 state. You should
58.
by aturon 12y ago
> By far the biggest demand for HKT is from people who are requesting Haskell-like do-notation for error handling. That hasn't been my experience -- we are constantly running into cases in the libraries where we need HKT to expres
59.
by aturon 12y ago
We do plan to add some version of this RFC, but made a careful decision about not including it for 1.0. It will not completely change the error-handling design, but rather empower it with additional, finer-grained control. It's possibl
60.
by aturon 12y ago
The team has actually been pretty careful to design in a HKT-compatible way. While there isn't a fully-fleshed out design yet for Rust, there are designs in other languages, and we've looked at their pitfalls to make sure we can a

More ›