search

haskell-distributed / distributed-process-platform

DEPRECATED (Cloud Haskell Platform) in favor of distributed-process-extras, distributed-process-async, distributed-process-client-server, distributed-process-registry, distributed-process-supervisor, distributed-process-task and distributed-process-execution
http://haskell-distributed.github.com
BSD 3-Clause "New" or "Revised" License
47 stars 18 forks source link

ProcessId wrapper for hot-loading/migration #43

Open jepst opened 11 years ago

jepst commented 11 years ago

An obstacle to migrating processes between nodes is how to deal with ProcessIds.

If we assume that any process can be migrated to another node at any time, ProcessIds are no longer reliable. Instead, we need another way to refer to migratable processes.

This problem may be separable into two sub-problems:

  1. Within an Application which will be migrated as a whole, processes may refer to each other. Here, it may be possible to substitute ProcessIds with correct values as part of migration.
  2. References by ProcessId to the Application from elsewhere will need to be updated.

It might make sense to establish a wrapper type, MigratableProcessId, that provides this additional layer of indirection. Sending a message to a MigratableProcessId will resolve to the actual current ProcessId of the given process.

hyperthunk commented 11 years ago

An obstacle to migrating processes between nodes is how to deal with ProcessIds.

There are other obstacles too. Whilst I think migrating between nodes might be do-able, I'm not done with exploring the possibility of loading changes on the fly in a running executable. Isolating dynamically loaded entities is possible, dynamic loaded does work (as plugins/hs-plugins demonstrates), safecopy or something like it might provide the means to deal with conversions....

We will see. But I do think migrating process state would be easier and therefore this enhancement remains a perfectly valid proposal until we decide what we want to do.