New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add In-types (concurrency) #494

merged 8 commits into from Jan 14, 2018


None yet
1 participant

bvssvni commented Jan 11, 2018

For design, see #495

How the go keyword works in Dyon

Dyon uses the go keyword to create new threads.

th := go run()    // Creates a new thread that calls `run`.
_ := join(thread: th) // Wait for thread to finish.

How current objects work in Dyon

Dyon uses current objects instead of globals.

fn main() {
    ~ a := [1, 2, 3]    // Create current object `a`.

fn foo() ~ mut a: [] {
    push(mut a, 4)

The problem with current objects is that they can not be shared across threads.

How the In-type works in Dyon

The in <fn> syntax is used to create a receiver channel. It receives input data when the function is called.

fn main() {
    foo_log := in foo    // Subscribe on input data when `foo` is called.
    th := go run()
    _ := join(thread: th)
    loop {
        x := next(foo_log)
        if x == none() {break}

// This function is used to send data between threads.
fn foo(x: f64) {}

fn run() -> bool {
    foo(1)  // Send `[1]`
    foo(2)  // Send `[2]`
    foo(3)  // Send `[3]`
    return true


The idea behind this came from a very strange angle and got reduced to the simplest possible design for Dyon. It seems to be a nice way of doing concurrency. Another usage I had in mind was easier debugging, since I often want to print out what happens somewhere without inserting print statements.

I decided to make it easier to integrate with other patterns of receiver/sender and using Rust's channels for integration.

The inspiration for this design came from a discussion about generalizing texture servers to arbitrary data for game development. One key idea was to register "workers" without recompiling that automated some part of the process. When studying the mathematical properties of the workers, I realized they had to exchange type information with the server, and this got me thinking about path semantics and Dyon. Path semantics has something called "paths" that are functions describing other functions. In the context of workers, I could create a special version that was limited to partial space-time, where the running time of the program is most interesting. My original idea was to create a constraint filter ∀f{[g] b} and ∃f{[g] b} that were sampled, so to ground the sampling one would need to use in foo \(x) = g(x) == b and out foo \(x) = g(x) == b. Starting with the in syntax, I figured the filter would be too hard to program and a lot of unnecessary overhead that could be moved to the receiver side. All I needed was the function input. So, I ended up working on concurrency for Dyon instead!

@bvssvni bvssvni merged commit 8c2ff33 into PistonDevelopers:master Jan 14, 2018

@bvssvni bvssvni deleted the bvssvni:awareness branch Jan 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment