Linux-Entwickler werden sicherlich die Funktion fork() kennen. Der Systemaufruf führt dazu, dass der aufrufende Prozess geklont wird, als child process („Kindprozess“) vom parent process („Elternprozess“) nach dem Klonen entkoppelt wird und andere Wege gehen kann, um z.B. sich durch ein anderes executable zu ersetzen. Dadurch, dass der Klon als Kindprozess läuft, entsteht eine baumartige Struktur, welche die Grundlage des Prozessmanagements unter unixoden Betriebssystemen bildet. Beispiel gefällig? Einfach mal ps -ejH im Terminal ausprobieren. Soweit, so bekannt.
Umso interessanter finde ich die Tech Demo, die Tristan Hume in seinem Blogartikel beschreibt. Er hat telefork in die Welt gesetzt, was es ermöglichen soll, Prozesse nicht nur auf der lokalen Maschine, sondern durch das Netzwerk zu forken, sodass der Prozess samt Umgebung, d.h. file descriptors, memory maps, etc. auf einer anderen Maschine weiterlaufen kann. Dies ist ein entscheidender Vorteil, da aufwändiges IPC oft viel boilerplate code abverlangt.
Mit telefork könnte Code dann z.B. folgendermaßen aussehen:
// load the scene locally, this might require loading local scene files to memory
let scene = create_scene();
let mut backbuffer = vec![Vec3::new(0.0, 0.0, 0.0); width * height];
telefork::yoyo(destination, || {
// do a big ray tracing job on the remote server with many cores!
render_scene(&scene, width, height, &mut backbuffer);
});
// write out the result to the local file system
save_png_file(width, height, &backbuffer);
Hier wird der Prozess einfach durchs Netzwerk geforkt und render_scene() dann ausgeführt. Der Renderjob kann dann auf einer z.B. leistungsstarken Cloud-VM ausgeführt werden und das Ergebnis zurückstreamen. Aus meiner Sicht ein interessantes Konzept, wenn auch noch in einer frühen Entwicklungsphase.
Der Blogartikel ist empfehlenswert und wer sich den sehr ausführlich dokumentierten (Rust) Source Code anschauen möchte, kann dies auf GitHub tun.
tux.