Custom CLR Host - "Pause"/"Resume" Application

Question

I've been looking at the ability to pause and resume a .Net application as of late, particularly with an eye towards being able to pause an application, store its state, and launch it again later.

I've been looking at the options provided by writing a custom CLR Host, an arcane art to be sure. It appears that a custom host can provide its own implementations for tasks, memory management, locks, etc. So from this it looks like I might be able to create a custom CLR Host that can pause and resume an application via ICLRTask, but I'm not sure the interfaces provided have enough hooks to pause all the tasks, store the entire program state to disk, and then bring the application back to life at a later point. Can someone definitively tell me that it's not possible at all? I also don't mind if it's only possible for a small subset of applications, I'm just curious about the possibilities here.

Answer 1

Sorry to have to rain on your parade, but that's not going to fly. The ICLRTask interface was added at the express request from the SQL Server team. They support the SQLCLR host, a custom hosting of the CLR to allow programmers to write managed code in stored procedures. They asked the CLR team to break the hard link between a managed Thread and an operating system thread, ProcessThread in the current framework. With the intention of implementing managed threads as fibers, a core feature of SQL Server at the time.

That did not actually happen, they couldn't get it reliable enough and gave up on the project. And the project was rapidly running out of reasons to make it work, fibers are no match for multi-core cpus with their own L1 cache.

Which doesn't have a heckofalot to do with what you are trying to accomplish. By far the toughest nut to crack, beyond reliably capturing the process state, is that you can't really deal with threads that are executing native code. Particularly the kind that pinvoked a winapi function and are blocking on a kernel driver to finish an I/O request. You can't capture the kernel state, nor do you have a hook. Adding hooks to the pinvoke marshaller would make it too slow. Hibernate is a system feature, it can't be a process feature.

Answer 2

The ability to suspend a running process, then serialize and move to another machine (or a later time) and resume was implemented on the Mono runtime when it was integrated as the Second Life script engine. This was a few years ago, and I'm not sure whether that work was incorporated back into the open source Mono code. But by all reports it was a successful exercise.

This blog post from Miguel might be a good start http://tirania.org/blog/archive/2008/Jan-29.html and has some more links to a LANG.NET video where the Second Life on Mono work was discussed.

Some more clues about what exactly was done from another post:

In 2006, Jim from LindenLabs introduced the work that they had done in SecondLife to support microthreading.

Jim's work was a lot more ambitious than what both Joe had requested. SecondLife required that code be suspended at any point in time and that its entire state be serializable into a format suitable for storage into a database. Serialized state could then be restored at a different point in time or on a different computer (for example while moving from node to node).

For this to work, they needed a system that would track precisely the entire call stack chain, local variables and parameters as well as being able to suspend the code at any point.

Jim did this by using a CIL rewriting engine that injected the state serialization and reincarnation into an existing CIL instructions stream. He covered the technology in detail in his Lang.NET talk in 2006.

The technology went in production in 2008 and today this continuation framework powers 10 million Mono scripts on SecondLife.