-
Notifications
You must be signed in to change notification settings - Fork 10
Description
I thought about modeling our concurrency primitives as function, instead of syntactic constructions or overloading the rfork call. The idea would be to have two builtin functions:
- go()
- channel()
The go function will receive a function as parameter and execute it concurrently, like the go keyword:
go(fn() {
# Do concurrent stuff
})
The semantics would be fairly similar to Go's (as usual =)).
The trick is on modeling channels as functions, with the channel function returning 3 values, the receive, the send, and the close functions:
receive, send, close <= channel()
The receive and send functions works in pair, calling receive blocks until send is called, and vice-versa.
If the idea makes sense, we need to define how to support buffered channels, and semantics on closed channels. It could be simpler than Go's and not have any kind of select magic, just to enable very simple usages.
One that is very common is when you want to wait for N operations to end, it could be something like this (I'll assume integers to make it simpler):
receive, send, close <= channel()
tasks = 10
for i = 0; i < $tasks; i++ {
go(fn(){
_, status <= cmd arg
send($status)
})
}
for i = 0; i < $tasks; i++ {
status <= receive()
print($status)
})
}
close()
Lot of this code is boilerplate and further functions could make it even simpler, specially to when you just want to exec N concurrent versions of a command and wait for all to end, it could be modeled as a helper function on the stdlib.
This idea is on EXTREME draft phase =)