processes

[Samuel Gaist]

On 4 août 2014, at 19:57, Aaron J. Seigo <aseigo at kde.org> wrote:

> Hi everyone ... 
> 
> Was a busy week for me here (including a laptop hardware failure... meh) so 
> didn't get back to the list until now. I have continued to push forward the 
> specifications, however, and after a good number of revisions processes and 
> supervision are ready for your review and feedback.
> 
> One of the key features of funq will be these in-process "processes"; much 
> like green threads which are run inside a VM and look like threads to the 
> application but which are not actually native threads, these "green processes" 
> look and behave very much like "real" OS processes but are just long-running 
> functions which have their execution transparently suspended and started by a 
> scheduler in the VM. This makes them quite cheap and a lot less complex to 
> handle.
> 
> The goal is to encourage breaking applications up into many cooperative 
> processes. This allows:
> 
> * compartmentalizing failure: an error in one part of the code leading to a 
> crash will not bring down the whole application
> * confident coding: most of us have been taught to check and catch all error 
> conditions in our code; not only do many developers fail to do this, but it 
> leads to hard to maintain code in many cases. If it is a valid idiom to allow 
> an error to crash a component, then one can ignore most errors and only code 
> for the success paths. A crash then becomes a generic error handler which the 
> application can cope with easily.
> * concurrency: each VM will be able to run 1 or more schedulers and divide the 
> running processes between them; this will allow applications to scale along 
> with the number of processor cores available to it
> * distribution: rather than having to run an entire application on just one 
> computer system, breaking things into processes will allow an application to 
> be distributed across multiple discreet computers at runtime and largely 
> transparently to the application.[1]
> 
> In support of these goals, two important features are available:
> 
> 1) Message queues: each process gets a message queue and processes can send 
> messages to each other. These message queues are asynchronous and can be 
> filtered by the receiver
> 
> 2) Supervisors: a supervisor is a process whose only job is to start process 
> and sit and then watch them. Supervisors can restart processes when they crash 
> (supports the 'confident coding' concept) as well as manage pools of resources 
> (e.g. a pool of database connection processes)
> 
> I have documented processes and supervision as I currently intend to implement 
> in the git repository under docs/processes.md and docs/supervision.md.
> 
> Feedback on them is most welcome ....
> 
> A quick overview of relevant API:
> 
> // start a process
> PID = std.process::exec(MyModule::MyFunc, [param1, param2]);
> 
> // send a message to a process without expecting a reply
> { $numbers, [1, 2, 3] } -> PID;
> 
> // send a message to a process as a two-way conversation
> ConversationId = { $numbers, [1, 2, 3] } <-> PID;
> 
> Those are the most important basics when it comes to processes. I'll touch on 
> supervision in the next email ...
> 
> [1] this opens the door to some truly exciting prospects such as pratical 
> multi-agent systems 
> 
> -- 

About scheduling, you wrote that it will be run-time configurable. Does it mean there's only one scheduler implementation that can be tweaked ? Or will there be several (e.g. Network priority / IO Priority etc…) that one can switch dynamically ?