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”.
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.
Well this is just stating a tautology isn’t it?
Edit:
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”.