What are the relative merits (or demerits) for implementing an Erlang-style Continuation pattern in C#. I'm working on a project that has a large number of Lowest priority threads and I'm wondering if my approach may be all wrong. It would seem there is a reasonable upper limit to the number of long-running threads that any one Process 'should' spawn. With that said, I'm not sure what would signal the tipping-point for too many thread or when alternate patterns such as Continuation would be more suitable. In this case, many of the threads do a small amount of work and then sleep until woken to go again (Ex. Heartbeat, purge caches, etc...). This continues for the life of the Process.
What are the relative merits for implementing an Erlang-style Continuation pattern in C#
c#;design patterns;multithreading;concurrency;erlang
A thread model is really more for when a task is continually running.  What you're describing is more of an event model.  In response to a timer elapsing, you run through a function once, then the timer is reset.  You only have enough threads to handle whatever events are running at any given moment, and you can have a ton of pending timers without even noticing.  Continuations are kind of a workaround to allow you to retain state in functional programming, but retaining state is what objects are all about.  Store whatever you need in a field, and it will be available to you the next time the event fires.