Rust

5953 readers

14 users here now

Welcome to the Rust community! This is a place to discuss about the Rust programming language.

Wormhole

!performance@programming.dev

Credits

The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)

founded 1 year ago

MODERATORS

snowe@programming.dev

Ategon@programming.dev

EdTheLegendary@programming.dev

kahnclusions@programming.dev

torcherist@programming.dev

Blocking code is a leaky abstraction – notgull (notgull.net)

submitted 2 weeks ago* (last edited 2 weeks ago) by snaggen@programming.dev to c/rust@programming.dev

4 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] MadhuGururajan@programming.dev 5 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

I am quite cheeky for saying this but:

How is it leaky if the default paradigm of any sequential program is the expectation that it will block? If i write blocking socket code I know my thread is blocked until read() returns.

If i am writing async socket code I know to wait for poll or whatever it is that is the correct way to wait nowadays. My design would reflect that. The blocking is just moved to another thread effectively and this abstraction is packaged as a Future.

Asynchronous code does not require the rest of your code to be asynchronous. I can’t say the same for blocking code.

Well this is just stating a tautology isn't it?

Edit:

It would be a Hurculean effort, and I don’t think it’s a sustainable approach. If you’re writing a higher level library, it would be a lot to ask to check if your dependency’s dependency’s dependency maybe reads from a socket.

I guess I understand what's the argument here.

The author wants a safeguard against libraries that are blocking with compiler checks. I agree it is a nice thing to have. But they could have mentioned that without saying "blocking code is leaky abstraction".

[–] BB_C@programming.dev 4 points 2 weeks ago

Maybe this is a reductionist simplification of it, but his point is basically that, at least in the context of rust, async code is explicit and easy to introduce in a blocking context by simply blocking on it, while blocking code is not explicit about how blocky it is (and it's not a binary), and thus, it's not trivial to know where explicit unblocks are needed in an async context.

Blocking on async code is usually done with some_executor::block_on(), of which some very lightweight implementations exist, combined with the possibility of not requiring that the data's ownership be moved to the executor, nor is the data required to be Sendable to other threads (an executor doesn't have to be a multi-threaded work-stealing one).

Meanwhile, unblocking is done usually via blocking::unblock() or some_executor::spawn_blocking(), and doesn't offer such flexibility.