Skip to content

Latest commit

 

History

History
55 lines (31 loc) · 3.41 KB

concurrency.md

File metadata and controls

55 lines (31 loc) · 3.41 KB

Concurrency

Concurrency is difficult. Most enterprise programming languages use async / await. Which works well enough and can easily have a stack-based implementation.

Silicon wants to do something better. Go uses CSP with channels. The main improvement over async / await is that this means no colored functions because Go has multiple execuction stacks.

This is pretty similar BUT still inferior to proper coroutines like in Lua or fibers in Ruby which also have their own execution stacks. Those implementations, like processes in Elixir allow for distributed computing models. Elixir uses the Actor Model which is just more restrictive than channels. Actors communicate directly with one another, like OOP. Versus through channels, which reminds me of queues. Channels allow a simple pub/sub model.

Coroutines can call other coroutines, they don't yield to any "parent" but pass data. They are co-operative routines after-all. They're asymmetrical meaning there are separate methods for resuming and pausing a coroutine.

"Actors are a combination of a Coroutine and a Channel. You can send information off to an actor. The actor operates within a Coroutine and reads from that channel to process work. Channels are the way for you to communicate safely between Coroutines."

Actors typically communicate directly to each other via their 'mailbox' but maybe that 'mailbox' aka channel could be shared? This decouples actors from one another.

Actors can only send one message directly to one other actor. Actor <-> Actor

Goroutines may talk via typed channels (first class constructs) which may have many Goroutines listening in on that channel. Basically a shared 'mailbox' in Actor model lingo.

Goroutine(s) <-> Channel <-> Goroutine(s)

coroutine_1 -> channel_A -> coroutine_2 courtine_2 -> channel_A -> coroutine_1

thoughts

Some say Lua's coroutines are better, others say Go's are better. Go's goroutines can't be paused or resumed like Lua's, nor passed around.

Crystals

Silicon's coroutines are called Crystals. Mainly because that fits the theme AND a separate term can capture its unique semantics and features without confusing them with other co-routine implementations.

channel

Silicon has typed channels. Channels are the intermediary. Crystals may subscribe to 0 or more channels. Crystals can act like Actors which means they can communicate directly if desired.

crystal

Crystals are coroutines, green threads. They CAN run in separate OS threads but they don't have to. They are managed by the runtime, not the OS. Coroutines have three methods: resume(), pause(), and status(). Coroutines can be passed as well. They may subscribe to 0 or more channels as well. Crystals can communicate across machines and domains I.E client <-> server.

They each of a pid`` or processor id. They may be addressed directly or indirectly through an associated channel`.

@let countingChannel = new chan();
@let count:co = new co(countingChannel)
count.resume()

sRPC

std contains a library for RPC. This allows for functions or crystals to communicate across boundaries.

CFRDT ?

Conflict-free replicated data-type