processes

[Aaron J. Seigo]

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 

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://kde.org/pipermail/funq-devel/attachments/20140804/e472399d/attachment.sig>