Pre-empting a function using a time-slice effect

[cimtrae]

Hi Is it possible to implement an effect that causes a function to yield back to the handler after a fixed time of execution? I think this should be possible as loops are actually implemented as function calls and we should be able to maintain a count of operations or call depth. I am interested in writing a library in Koka that provides an Erlang like run-time where child processes are pre-emptively switched even if they don't yield by calling an io effect for example. Such a run time would provide Erlang like simplicity for concurrency and fault tolerance but the speed, efficiency and the elegance of Koka language.

[daanx]

Interesting :-) However, there is currently no way to pre-empt code; even though loops are function calls in Koka, these are optimized back to direct loops in the C code. A potentially better way would be through the allocator. Koka uses mimalloc which can guarantee a "heartbeat" callback (but this only works if your code still allocates).

However, there is a big drawback to general pre-emption as it could violate invariants unless the user writes guarded blocks that cannot be pre-empted but that is quite cumbersome. Here, the asynchronous model works really well -- all I/O bound computation is running in async mode where we any asynchronous strand ("thread") can be canceled: cancellation results in the next async call raising an exception (actually, the cancel effect) and unwinding neatly. Moreover, that allows one to set a compositional and robust time-out over any asynchronous code. I write about this here: https://www.microsoft.com/en-us/research/wp-content/uploads/2017/05/asynceffects-msr-tr-2017-21.pdf

So, the current plan is to first create a binding to libuv and revive the std/async module and use that for I/O bound computations; and then things like parallel map of pure functions for any CPU bound computation. I think the libuv binding is a bit hard to do as it requires compiler modifications but I am working on it; after that there should be lots of space to play with cool new asynchronous/parallel designs :-)

[cimtrae]

Thanks. I will wait on the libuv bindings as it will address most use cases. You are correct about general pre-emption. It will work safely only if the memory is not shared like in actor model otherwise we need guard blocks etc.. Jus as an aside it would be interesting to hear what you think about actor model.

[iacore]

A few suggestions on implementation

• use libinger
• use a thread and wait on it
• use actor API like Pony

A few problems: what if the the task is paused in the middle of effect handler? At least pure a is easy to implement, but other effects are weird.