I feel the goal of a tool should be to make common patterns easy to represent: so "sprinkling async everywhere" only doesn't work because of some common desirable pattern not being easily representable in modern languages and gotchas of the languages.
I have a lightweight thread scheduler written in C and I communicate between threads with a lockless ringbuffer. IO threads do IO. I like the idea of event loops and libuv but I want parallelism.
I wanted to understand how to compile async/await so I wrote a multithreaded unrolled state machine in Java. Each async keyword sends to another thread. I haven't got it to send to a different thread each time to load balance, I need to spend more time on it.
task1:
handle1 = async task2();
handle2 = async task3();
handle3 = async task4();
// at this point, I want task2, task3, task4 to be going on in parallel ON DIFFERENT threads
await handle1;
await handle2;
await handle3;
I am designing a notation for concurrency and asynchronocity that is a directly a state machine. I need to write a specification and I'm working on a Java runtime. It looks like this. It's inspired by BNF and Prolog facts.
Take a look at Cilk (a lightweight C first and C++ later dialect) that pretty much uses the same syntax you are using. Scheduling is done via workstealing.
The Cilk papers in particular are very very good. They discuss the programming model, the compilation strategy, the scheduling algorithms and more.
Rust explicitly has "Send" and "non-Send" futures that can execute either on any thread, or always on the same thread. Details depend on the executor, and you can roll your own if you want.
This works in Rust:
let thread_s = spawn(join!(state1(yes), send(message), receive(message2));
let thread_r = spawn(join!(state1(yes), receive(message), send(message2));
I am coming from the perspective of states and behaviour. I have read about session types but my syntax is not inspired by them.
Types are important and useful but I am more interested in the rigid parts of code that types data flow through otherwise known as control flow. I feel it's an ignored part of computer science.
My goal is easy parallelism, asynchronocity and reactivity.
I feel the goal of a tool should be to make common patterns easy to represent: so "sprinkling async everywhere" only doesn't work because of some common desirable pattern not being easily representable in modern languages and gotchas of the languages.
I have a lightweight thread scheduler written in C and I communicate between threads with a lockless ringbuffer. IO threads do IO. I like the idea of event loops and libuv but I want parallelism.
I wanted to understand how to compile async/await so I wrote a multithreaded unrolled state machine in Java. Each async keyword sends to another thread. I haven't got it to send to a different thread each time to load balance, I need to spend more time on it.
I am designing a notation for concurrency and asynchronocity that is a directly a state machine. I need to write a specification and I'm working on a Java runtime. It looks like this. It's inspired by BNF and Prolog facts. I am inspired by Pony lang, Go and Erlang but I think there's still lots of potential innovation in this space that could be had.