-
Notifications
You must be signed in to change notification settings - Fork 25
RFC: Non Kappa Capabilities in Encore
Capability to access the surrounding system should be passed as an argument to the main method. Logically (or possibly even in practise), the surroundings should be an actor. Printing to the terminal, opening files, etc. are operations that this actor supports.
The ability to block/actively use cooperative scheduling should also be a capability. An "interruptible method", i.e. one that might call get/await/suspend/another interruptible method needs to have such a capability passed in. When created, an active object can request an "interruptible capability". The difference between an active object and an actor is whether it has such a capability or not.
Calling get consumes the interruptible capability (to be returned when the get is done), meaning an active object can only be blocking on one get at a time. Await/suspend does not consume the capability.
Capability to execute a method in its own thread is similar to the interruptible capability. A passive object does not have such a capability and borrows the thread of the caller to perform an operation. An actor has such a capability. A hot object may have zero or one. Normal actor methods will consume the capability, only one behaviour at a time is supported. Methods inside a lock-free capability does not consume this capability, meaning multiple such methods can be active in parallel.
- An object which is not interruptible will not participate in deadlocks.
- An object which is not interruptible will not make use of Encore threads.
- An object which does not have an execute capability will be called synchronously.