"Steffen Märcker"<
[hidden email]> wrote:
> today I've tried to use the Polycephaly package to get some heavy
> compuations done by drone images. However, my application generates some
> code (namespaces, classes and shared vars) during runtime _before_ I start
> any drone image, but I ran into some OSTransferError. It seems that
> everything has to be defined in the applications startup image _on_disk_.
> I've been able to circumvent this by taking a snapshot right before
> starting up the drones.
>
> However, ss there another way to propagate the image's current state to
> these drones instead of snapshotting to disk?
>
> Btw: great package - just KISS!
Yup, that's the crux of the problem :-). I explored the issue of separating task configuration from the task run few years ago. The experiment is available in the public repository in a bundle called Grid (see the bundle comment for more details). Here's a short excerpt that seems relevant:
---
GridDrone is a generic package meant to be used on any number of clients. When loaded the client image is supposed to contact a system running a GridController, at which point it is added to the drone pool of the controller.
The purpose of a GridController is to execute a job, consisting of a number of tasks. It distributes tasks among its drones, coordinates their execution and collects results. Therefore a task goes through following phases:
1) Configuration: The drone is loaded with task specific code and instructed what to do (#do:* variants)
2) Execution: The drone is instructed to execute the task along with any task parameters specific for a given task run (#go* variants)
3) Result Collection: The drone forwards the task run result using a callback. By default the callback is targetted at the controller using a predefined selector #reply:from:in:. Note that the drone can be instructed to use other reply destination and selector in step 2.
---
This was all based around Opentalk and didn't deal with the issue of actually activating the drone images. My direction back then was more towards SETI like setup where the drones are maintained explicitly and get discovered via multicast if on the same LAN or through explicit contact. The grid controller just had to make do with whatever number of drones it had available. Poly on the other hand doesn't rely on anything, is very simple, but only runs on a single host.
I'm not sure if a hybrid of the two would be better than just keeping those two approaches separate.
Martin
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Locked
