carllerche

13 ms·

91.
by carllerche 7y ago
Assuming [this]( https://github.com/fastflow/fastflow/blob/master/ff/buffer.h... ) is the FFBuffer in question, it looks like it is spsc (which would not support stealing). Also, it would need some
92.
by carllerche 7y ago
Yes! Rayon is the perfect use case for the Chase-Lev queue!
93.
by carllerche 7y ago
True... correctness is very important! I made mention of loom for correctness in the intro at least. The goal for this article was primarily to focus on scheduler design. I'm hoping to get posts dedicated to loom soon. It's been a
94.
by carllerche 7y ago
Relaxed ordering impacts the compiler. There are a number of optimizations it cannot make. I am not sure exactly what those are, but it is measurable.
95.
by carllerche 7y ago
Ah, all the helpers around the "FSM" aspect of things are already exposed as part of the `futures` crate: https://github.com/rust-lang-nursery/futures-rs/
96.
by carllerche 7y ago
`unsync_load` reads the memory as if it were a normal field (no atomic operation). The `std` atomic types already provide `get_mut` which gives access to the "raw" field when the caller has a mutable reference to the atomic. The m
97.
by carllerche 7y ago
My understanding of that PR is it relates to how the Go compiler does code generation. Rust takes a different approach and is about to ship `async / await` which is a different strategy. Preemption is out of scope for Tokio as we are f
98.
by carllerche 7y ago
> So the question here is why not to expose generic state machine framework (FSM/HSM) which can deal with those protocols but is also very useful for many other tasks as well? Short answer is: you can. Tokio is more like "node.
99.
by carllerche 7y ago
"Node for Rust" is a good way to think about it! From what I know about Akka, I believe Akka does more than Tokio. For example, Akka manages a supervision tree. I believe Akka is trying to be more of an actor system where as Tokio
100.
by carllerche 7y ago
Thanks! I agree with your assessment of the Mutex. Improving that is included in the follow up work. I could have kept working on this for many more months... but my collaborators were starting to get grumpy and telling me to ship already
101.
by carllerche 7y ago
Author here. I'll be watching the comments and can answer any questions! I do want to make clear that most of the optimizations discussed are implemented in the Go scheduler, which is where I discovered them. I wrote the article to cal
102.
by carllerche 7y ago
From that section. > There are multiple processors, each running on a separate thread. It's probably easy to miss, do you have thoughts on where else this can be clarified?
103.
by carllerche 7y ago
That makes sense to me :) Excited to see that happen!
104.
by carllerche 7y ago
There is one processor per thread. Sorry, the article must not have been clear. If you can point out where in the article you got the impression there were multiple processors per thread, I can try to update the article to fix.
105.
Tonic: gRPC has come to Rust and async/await(luciofran.co)
11 points by carllerche 7y ago|0 comments
106.
by carllerche 7y ago
> tokio, wasn't very efficient at changing events in the queue (requiring a an extra self signal to get the job done). Could you expand on that?
107.
by carllerche 7y ago
How is the topology discovered without tracing? The article mentions that metrics are used. Could you elaborate on how you go from metrics to the topology?
108.
by carllerche 8y ago
Also, a lot of the work on Tokio [1], Tower [2], and the Rust HTTP/2.0 implementation [3] is being driven by linkerd 2.0 (and sponsored by Buoyant). [1]: http://github.com/tokio-rs/tokio [2]: http://git
109.
by carllerche 9y ago
I would say that you could start using it if: * You are ready to become an active contributor to the project. * You are brave!
110.
by carllerche 9y ago
I had good luck. As mentioned above, finding a good GC is not easy because they do not advertise. It is entirely word of mouth. I live in the pacific NW where there are a lot of old craftsman style homes. High quality woodwork details is th
111.
by carllerche 9y ago
You can get this working with Tokio if you know what you are doing. However, I personally advise against it as I have found that deferring to the OS for scheduling results in poor thread affinity (your state gets bounced around threads unne
112.
by carllerche 9y ago
Tokio is about being flexible (true today, even more true in the upcoming release). It is more about set of primitives that you can assemble in a way that fits your needs. You can structure the concurrency of your application however you wa
113.
by carllerche 9y ago
Yes you can do this. The actual socket is not pinned to any thread, so you can move it to a thread pool or whatever.
114.
by carllerche 9y ago
I'm (one of) the author of Tokio, hopefully I can clarify some points. > Unfortunately, Tokio is notoriously difficult to learn due to its sophisticated abstractions. IMO, this is largely due to the current state of the docs (which
115.
by carllerche 9y ago
One can spawn as many reactors as you would like. The only thing a reactor does is receive events off of epoll (or other system selector) and notify the associated task. The task could be on the reactor thread or across a different thread.
116.
by carllerche 9y ago
The futures underpinning of Tokio actually doesn't have much to do with futures. The task system is really what is special about it (though, currently futures are the main way it is exposed) however, there is a lot of potential other r
117.
by carllerche 9y ago
I'm curious what gives you that impression. What do you think is missing or should be tackled sooner than later? There has been a lot of evolution, however it has all been done in backwards compatible ways so there has not yet been a n
118.
by carllerche 10y ago
Rust uses type inference to figure that out. Because `addr` gets passed to `TcpListener::bind` which requires a `SocketAddr`, the type inferencer knows that `addr` should be a SocketAddr and so it all works :)
119.
by carllerche 10y ago
Hey, I'm the one who received the MOSS award to work on Mio. Funny hearing about this today. The goal of the Mio work is, in part, to implement a higher level, future based API on top of Mio. The award has been amazingly helpful to all
120.
by carllerche 10y ago
There is a lot in the pipeline! I'll be talking more about it soon.

More ›