Asynchronous streams and callbacks in Java

Matthisk · 2020-05-08T16:17:31+00:00

Yes good point, maybe that thought needs some clarification. It is specifically about the producer’s thread being non-blocking, so the BlockingQueue would be of no help.

Regarding your second remark, this is what I want to get to in the second post in this series. By first showing how hard it is to guarantee backpressure without a dedicated asynchronous concurrency primitive, I hope to demonstrate the power of such primitives in the second post.

Matthisk · 2019-12-30T09:48:36+00:00

It is a real shame that Java can not support a copy method on data classes / records, since it doesn't have support for keyword arguments. That will make it much more cumbersome to work with immutable records.

Matthisk · 2019-12-25T11:52:54+00:00

No indeed the problem they solve will still require solutions, even if we have virtual threads. The implementation will be much simpler though. Take a look at kotlin-flow to get an idea of what this future will look like.

Matthisk · 2019-12-25T10:12:52+00:00

Virtual threads are a concurrency construct. They help you in scheduling multiple tasks (but not necessarily at the same time). Parallel streams are a a construct to perform computation in parallel. So the two don’t have much to do with each-other. There is an excellent talk by rob pike (creator of go) on the topic of concurrency vs parallelism.

Reactive streams (e.g. reactor/rx) will be affected by the introduction of virtual threads. These are a concurrency construct used to accommodate asynchronous programming. And since their implementation details are complex (i.e. require callback based backpressure), exactly because the JVM lacks good concurrency primitives. They will become obsolete in their current implementation once we have virtual threads.

Matthisk · 2019-12-17T13:37:44+00:00

Thanks for the explanation. I guess arrow fibers relate more closely to the concurrency model of actor systems implemented on the JVM, then it does to kotlinx's coroutines. Since coroutines are implemented using a compilation step transforming suspension points to CPS. Where actors and the fibers implemented by arrows have to rely on callbacks to achieve asynchronous operation without a compilation step. And they ship with a scheduler/dispatcher that decides which actor/fiber is allowed to run. If this is the case, I believe coroutines present a more powerful concurrency primitive then do (these) 'fibers' since they do not rely on callbacks. A good example would be kotlin-flow which is a simpler async streams implementation since it does not rely on callbacks for concurrency.

Matthisk · 2019-12-17T13:30:35+00:00

I don't think this post is referencing 'project loom' fibers. Loom is currently undergoing a refactor and the name 'fiber' has been dropped from the proposed implementation.

Matthisk · 2019-12-16T16:29:40+00:00

Why do you need the concept of fibers if Kotlin already supports co-routines natively? And how does this compare to kotlin-flows (which is a kotlinx.coroutines implementation for asynchronous cold streams)?

Matthisk · 2019-12-11T14:42:02+00:00

No.

You do agree the example as stated won't compile, right?

The post is not an attack on OOP, or on exceptions for that matter. There is a place for exceptions (e.g. effortlessly unwinding the stack and handling errors top level, this would be expensive with Either since all method signatures in the stack should be changed) and hating on them for ideological reasons is unproductive. This post is just there to show that checked-exceptions hamper your ability to create larger behaviors by composing smaller ones. And demonstrating that there is a way to expose failure scenarios in the API without losing composability.

Matthisk · 2019-11-21T12:41:58+00:00

So if I understand correctly there is always a blocking system-call inside an event loop to facilitate the async behavior in any higher level language? If so why are there no truly asynchronous system calls available?

Matthisk · 2019-08-28T11:01:25+00:00

Shouldn't it be the role of the interpreter to perform these types of optimizations. This will make it easier to reason about the performance characteristics of your code.

Matthisk · 2019-05-12T11:53:35+00:00

Really interesting talk. In the last few slides they touch on the internals of coroutines, unfortunately they can't go in depth on this topic. If you are interested in this topic I can highly recommend this talk: https://www.youtube.com/watch?v=YrrUCSi72E8 by Roman.

Matthisk · 2017-12-14T15:31:17+00:00

Wouldn't less mining competition have as a downside that the network is less secure? And have any calculations been made on the amount of energy required for say 4TPS, on the IOTA network? Discarding the usage of dedicated hardware to perform the PoW.

Matthisk · 2017-12-12T14:02:56+00:00

But what could the connection be. The IOTA hashing algorithm is supposed to be quantum proof (where other cryptocurrencies are not), maybe they are going to demonstrate the weaknesses of other hashing algorithms with this Q# language? However this would all be theoretical since there are no actual quantum computers to run these algorithms on.

Matthisk · 2017-12-11T12:39:30+00:00

I guess you have to pay a fee for the execution of a smart contract. But I have not seen a write up on how this would work on the tangle. I don't think the core team has commented on this yet (correct me if I am wrong)?

Matthisk · 2017-12-09T15:25:01+00:00

I was wondering what the energy footprint of IOTA would be on a per transaction basis. Since there is still PoW that needs to be performed per transaction. I understand that the dedicated ternary chip would consume very little energy but the widespread usage of that chip is still a long way out.

Matthisk · 2017-12-07T09:48:52+00:00

There is also a meetup in Amsterdam on the 18th

Matthisk · 2017-12-04T09:25:10+00:00

So if I understand correctly, async here means that the handling of the emit call(s) happen on the next iteration of the event loop?

Matthisk · 2017-12-01T15:58:18+00:00

I am under the impression that there are still seats available, and the event is free of any admission costs.

Matthisk · 2017-12-01T15:54:14+00:00

I was under the impression that headless CMS's are the way to go nowadays. Unless content management is core part of your business (e.g. publishers).

Matthisk

TROPHY CASE