5 ms·
Yes, they do. (That's why there's the monad transformer.) But this is fundamentally a very simple thing. If you use an async framework, you have to think insid
by pas 6y ago
Yes, they do. (That's why there's the monad transformer.)
But this is fundamentally a very simple thing. If you use an async framework, you have to think inside that. It's just as fundamental as CPU architecture, or operating system. If you have an Intel CPU you need a corresponding motherboard. If you have Windows you need programs that use the Win32 API (or use the necessary translation layer, like WSL).
Similarly, if you use - let's say - libuv in C, you can't just expect to call into the kernel and then merrily compose that with whatever libuv is doing.
This "coloring" is a suddenly overhyped aspect of programming (software engineering).
And of course fundamentally both are wrappable from the other, but it's good practice to don't mix sync/async libs and frameworks and components. (Or do it the right way, with separate threadpools, queues, pipes, or whatnot.)
- an_opabinia 6y ago> you can't just expect to call into the kernel and then merrily compose that with whatever libuv is doing. Quasar Fibers, which eliminated function coloring for Java async versus blocking IO, I wound up doing the equivalent of that in the Java ecosystem, and it works in production extremely well. Defeating the coloring problem makes gluing all sorts of really valuable stuff together much easier. In a world where you can’t just rewrite from scratch the things you’re gluing.
- panacpp 6y agohttps://web.archive.org/web/20170629202409/http://blog.paralleluniverse.co/2013/05/02/quasar-pulsar/ https://web.archive.org/web/20170629202409/http://blog.paral...
- Arnavion 6y agoThis kind of "transparent async" (like what golang also does) always has the danger of creating race-condition-style bugs, because some synchronous-looking piece of code doesn't run synchronously so some state at the beginning of the function has a different value at the end of the function. Have you had those kind of problems with your Java codebase?
- kjeetgill 6y ago> some synchronous-looking piece of code doesn't run synchronously so some state at the beginning of the function has a different value at the end of the function Does function coloring solve this? I don't think it's the case. Python, JS, etc. don't see this issue much because the interpreters tend to be single threaded or have GILs. C#, for instance, would see all the same issues a Java or Go program might with respect to variables changing over time.
- pas 6y agoOh, JS is full of such bugs, because it's trivial to write a loop that fires off async closures (Promises) that capture something by reference, so they then end up trampling all over each other.
- simiones 6y agoThis problem can also easily happen with async code, if you have any shared state with the async code, especially if you are running multiple async calls in parallel. It can even happen in single-threaded runtimes like Node, where people are even less likely to expect it.
- Arnavion 6y agoMy point is that "transparent async" code can lull the programmer into a false sense of security. Contrived example: void ChargeAccount(Account account, int cents) { int balance = account.balance; int newBalance = balance - cents; Logger.Write("changing account from {balance} to {newBalance}"); account.balance = newBalance; } This works fine because it's all synchronous code. Then someone classloads a Logger implementation that's "transparent async" because it logs to a network sink in addition to synchronous stderr, and now there's a chance two calls to ChargeAccount interleave and one of the charges is lost. If it's explicitly async with async-await keywords etc, then the race is easily noticeable and the programmer will know they have to use a mutex or atomics or whatever.
- 6y ago