2

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.

J Trana
  • 2,150
  • 2
  • 20
  • 32
  • 1
    To start with I don't know anything about custom CLR Hosts, so this is all speculation. Thinking about how it could work, I think it would only work for a subset of applications. This is because of things like file handles or other system resources that may not exist when you resume the program. Either your host or your application would have to be smart enough to know to try to re-request these external resources. And if you are having to make changes to your app to support the host, well I don't think you need the host in the first place cause your app can pause and resume itself anyway. – Steve May 26 '12 at 20:57
  • What about the Workflow Foundation (http://msdn.microsoft.com/en-us/netframework/aa663328.aspx)? This allows work to stop and be serialized, to be continued later. Nice pictures here: http://msdn.microsoft.com/en-us/library/dd851337.aspx. – Govert May 27 '12 at 13:48
  • @Govert I feel rather meh about Workflow Foundation. Something I found of interest in this whole conversation was a link talking about the concept of persistent iterators. A little hacky, but I think I may be able to do some good things with it... The link is here: http://dotnet.agilekiwi.com/blog/2007/05/implementing-workflow-with-persistent.html – J Trana May 29 '12 at 03:56
  • I'm not sure I'd like to depend on the compiler's iterator implementation, but a light-weight reflection-based workflow approach might be quite nice. I don't have much experience using WF, but with the major upgrade it got in .NET 4, it might be worth a revisit. There are other lightweight options too - see the links from here: http://stackoverflow.com/questions/932924/can-anyone-recommend-a-net-open-source-alternative-to-windows-workflow – Govert May 29 '12 at 14:14
  • Thanks @Govert for the reminder. My particular use case is part of what drives me away from WF. It's not so much that I'm opposed to WF for things like enterprise apps, etc., but I'm only using application state storage to essentially pause and resume for user-level type apps. If the state gets corrupted/is not upgradeable, a hard reset of the app is to be expected. In that case, I'd like to distort the normal C# development experience as little as possible to get the best bang for the buck. At least that's my opinion today. :D – J Trana May 29 '12 at 17:19

2 Answers2

3

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks for the great info! I'd seen the feature drop of SwitchOut, but I thought it had been implemented in later versions. You get my vote for a reliable answer on that alone! – J Trana May 26 '12 at 21:21
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.

Community
  • 1
  • 1
Govert
  • 16,387
  • 4
  • 60
  • 70
  • This is also freaking awesome! Thanks for the links. This maybe didn't answer my question exactly, but it definitely answered my intent. I'll definitely look through this carefully... – J Trana May 26 '12 at 21:39
  • thanks! So it appears that there were two similar works done about that time: some by a guy named Tomi and some by Linden Labs. Tomi's work (which did not support serialization natively) was picked up and folded back into Mono.Tasklets.Continuations (http://www.mono-project.com/Continuations). However, I'm not sure serialization support was ever added. Do you know if it was? If not, any clue if Linden Labs released their version of Mono? I've been doing a little digging but nothing so far... – J Trana May 27 '12 at 03:14
  • I'm not sure it's that similar. Continuations basically give you the plumbing for async, like C# 5 implements under the covers. The runtime serialization is hugely more complicated. You might ask on the Mono dev list: http://lists.ximian.com/mailman/listinfo/mono-devel-list. – Govert May 27 '12 at 10:27
  • True. Saying they're similar is liking saying apples and oranges are both fruit. If I recall, the Continuations implementation isn't well suited to serialization either, due to the way the memory is stored. I like how the video presentation Linden Labs put together presents the adaptations for that piece in a matter of a few minutes without hardly taking a breath for questions. Those guys must be geniuses! "Just a little CIL rewriting using RAIL..." *sighs* – J Trana May 28 '12 at 04:21