Asynchronous IO in Rust • Hacker News Board

Re: Asynchronous IO in Rust

#31

Post by pcwalton » Thu, Sep 17, 2015, 1:57 AM UTC

theseoafs wrote: post #6

pcwalton wrote: post #4

Earlier quoted context omitted.

> What's so wrong with Rust threads, excepting perhaps them being heavyweight? (Far better to solve that problem directly.) Nothing. If threads work fine, use them! That's what most Rust network apps do, and they work fine and run fast. A modern Linux kernel is very good at making 1:1 threading fast these days. > And having written network servers with pretty much every abstraction so much as mentioned in the article…

> Green threads didn't provide performance benefits over native threads in Rust. That's why they were removed. This seems wrong. This shouldn't be the point of green threads -- green threads aren't a "faster" alternative to native threads. How would that work? How could it be the case that virtual threads implemented in user space are faster than native threads provided by the OS? I don't think anyone expects that to…

I'm confused. To me, green threads are just an implementation detail. The fact that green threading is being used shouldn't leak into the interface. To take Go for an example, you could perfectly well write a conforming implementation of Go that used 1:1 native threading: it would just have different performance characteristics and things like LockOSThread() would become a no-op.

Could you elaborate on what you consider the interface difference to be?

Re: Asynchronous IO in Rust

#32

Post by sillysaurus3 » Thu, Sep 17, 2015, 2:17 AM UTC

pcwalton wrote: post #31

theseoafs wrote: post #6

Earlier quoted context omitted.

> Green threads didn't provide performance benefits over native threads in Rust. That's why they were removed. This seems wrong. This shouldn't be the point of green threads -- green threads aren't a "faster" alternative to native threads. How would that work? How could it be the case that virtual threads implemented in user space are faster than native threads provided by the OS? I don't think anyone expects that to…

I'm confused. To me, green threads are just an implementation detail. The fact that green threading is being used shouldn't leak into the interface. To take Go for an example, you could perfectly well write a conforming implementation of Go that used 1:1 native threading: it would just have different performance characteristics and things like LockOSThread() would become a no-op. Could you elaborate on what you consi…

The interface is different because if you use a green thread within a GC'd language, you can do anything -- change anything, interact with anything -- and nothing will crash. No locking involved, and no hidden locking under the hood.

It's not meant to be a performance boost, but a way of writing code where "might this crash?" is a question you're never bothered to ask. It's wonderfully freeing.

Not true of native threads. If a goroutine were replaced with a native thread, it would swiftly crash on GC.

Re: Asynchronous IO in Rust

#33

Post by theseoafs » Thu, Sep 17, 2015, 3:02 AM UTC

pcwalton wrote: post #31

theseoafs wrote: post #6

Earlier quoted context omitted.

> Green threads didn't provide performance benefits over native threads in Rust. That's why they were removed. This seems wrong. This shouldn't be the point of green threads -- green threads aren't a "faster" alternative to native threads. How would that work? How could it be the case that virtual threads implemented in user space are faster than native threads provided by the OS? I don't think anyone expects that to…

I'm confused. To me, green threads are just an implementation detail. The fact that green threading is being used shouldn't leak into the interface. To take Go for an example, you could perfectly well write a conforming implementation of Go that used 1:1 native threading: it would just have different performance characteristics and things like LockOSThread() would become a no-op. Could you elaborate on what you consi…

This is backwards. Green threading can be an implementation detail, but in languages where it's a key feature, green threads let you write code that would otherwise be incorrect. For example, in a native threading model, it is an awful idea to spawn a thread for every incoming connection on a server. It's the easy way to write it, but it's wrong. With a green threading model, though, that's easy and efficient.

Re: Asynchronous IO in Rust

#34

Post by theseoafs » Thu, Sep 17, 2015, 3:03 AM UTC

sillysaurus3 wrote: post #32

pcwalton wrote: post #31

Earlier quoted context omitted.

I'm confused. To me, green threads are just an implementation detail. The fact that green threading is being used shouldn't leak into the interface. To take Go for an example, you could perfectly well write a conforming implementation of Go that used 1:1 native threading: it would just have different performance characteristics and things like LockOSThread() would become a no-op. Could you elaborate on what you consi…

The interface is different because if you use a green thread within a GC'd language, you can do anything -- change anything, interact with anything -- and nothing will crash. No locking involved, and no hidden locking under the hood. It's not meant to be a performance boost, but a way of writing code where "might this crash?" is a question you're never bothered to ask. It's wonderfully freeing. Not true of native thr…

This is only true for n:1 green threading.

Re: Asynchronous IO in Rust

#35

Post by sillysaurus3 » Thu, Sep 17, 2015, 3:11 AM UTC

theseoafs wrote: post #34

sillysaurus3 wrote: post #32

Earlier quoted context omitted.

The interface is different because if you use a green thread within a GC'd language, you can do anything -- change anything, interact with anything -- and nothing will crash. No locking involved, and no hidden locking under the hood. It's not meant to be a performance boost, but a way of writing code where "might this crash?" is a question you're never bothered to ask. It's wonderfully freeing. Not true of native thr…

This is only true for n:1 green threading.

Sure. But I might write my n:1 code more quickly, robustly, and performant than your m:n code, since m:n forces the programmer to carefully worry about whether their code will break.

Re: Asynchronous IO in Rust

#36

Post by cwp » Thu, Sep 17, 2015, 3:16 AM UTC

jerf wrote: post #3

If you use threads, green or otherwise, you don't have to "implement" special code for composing things together, you get the full set of tools for composing code together, which includes, in passing, state machines, among all the other things it includes. This basically implements an Inner Platform Effect of an internal data-based language for concurrency that the language interprets, which will A: forever be weaker…

Isn't this a rehash of the C10K problem[1] from a decade ago? That was pretty much resolved in favour of single-threading and asynchronous IO, with Nginx and Node.js replacing Apache and Ruby as the platforms that the cool kids use.

So, if threads are the way to go today, what has changed in the last 10 years to turn the conventional wisdom on it's head? 64-bit processors and servers with more memory? Hypervisors/containers? Are threads in Rust more practical than they are in C?

(BTW, these aren't rhetorical questions, genuinely interested.)

[1] http://www.kegel.com/c10k.html

Re: Asynchronous IO in Rust

#37

Post by dboreham » Thu, Sep 17, 2015, 3:29 AM UTC

jerf wrote: post #17

tailhook wrote: post #10

Earlier quoted context omitted.

Well, I believe that it's almost impossible to make rust threads lightweight because every green thread needs a stack anyway. This may be fixed with some stuff like `async/await`. But let's talk about what's wrong with threads: 1. Timeout handling is ugly: you need to account a timeout in each read and write operation. At least timeout handling makes coroutine/threaded code no better than state machine code. But actu…

I've been writing in this model for nearly ten years now. In practice, what you cite as problems aren't. 1: In either approach, somewhere in your event loop you're setting yourself a timeout to fire. Haskell & Erlang do use exceptions, but Go does not, it simply makes this a first-class concern of the core event loop. This is only a problem in languages where the threading was bolted on after-the-fact. Which is a lot…

Somewhat depressing that the earliest "heated discussion" I remember about this was nearly 20 years ago. The outcome of that discussion (with Alan Freier about the M:N and cooperative threading implemented in NSPR at that time) was "if only we could just make threads work". Seems like progress has been pretty slow toward that goal, although Go has picked up the pace recently.

Re: Asynchronous IO in Rust

#38

Post by theseoafs » Thu, Sep 17, 2015, 3:29 AM UTC

sillysaurus3 wrote: post #35

theseoafs wrote: post #34

Earlier quoted context omitted.

This is only true for n:1 green threading.

Sure. But I might write my n:1 code more quickly, robustly, and performant than your m:n code, since m:n forces the programmer to carefully worry about whether their code will break.

Maybe, if my program has a lot of shared mutable state. I'm smart enough to avoid that though.

Re: Asynchronous IO in Rust

#39

Post by girvo » Thu, Sep 17, 2015, 3:31 AM UTC

cwp wrote: post #36

jerf wrote: post #3

If you use threads, green or otherwise, you don't have to "implement" special code for composing things together, you get the full set of tools for composing code together, which includes, in passing, state machines, among all the other things it includes. This basically implements an Inner Platform Effect of an internal data-based language for concurrency that the language interprets, which will A: forever be weaker…

Isn't this a rehash of the C10K problem[1] from a decade ago? That was pretty much resolved in favour of single-threading and asynchronous IO, with Nginx and Node.js replacing Apache and Ruby as the platforms that the cool kids use. So, if threads are the way to go today, what has changed in the last 10 years to turn the conventional wisdom on it's head? 64-bit processors and servers with more memory? Hypervisors/con…

More cores, perhaps? Though I don't know if that's actually true in a server context.

Re: Asynchronous IO in Rust

#40

Post by mtanski » Thu, Sep 17, 2015, 3:34 AM UTC

I think a lot of folks think of Network IO when they say Asynchronous IO. That's only half the story, unless you're just building proxies and caches you have to deal with Disk IO at some point in time. And, async disk IO is horrible in every OS / language.