Tasks, object lifetimes, and implicit cancellation

Background: The IMVU client has a system that we call the ‘task system’ which works a lot like lightweight threads or coroutines. You can schedule up some work which gives you back a Future object on which you can either wait or request the actual result (if it has materialized, that is).

I just read Joe Duffy’s IDisposable, finalization, and concurrency. The parallels between TPL and IMVU’s task system surprised me.

When we built the task system, there were two ways to cancel execution of a task: explicit and implicit. You could either call future.cancel() or just release your reference to the future and wait for it to be collected by the GC. In either case, the scheduler would notice and stop running your task. I’ve often wondered if support for implicit task cancellation was a good design.

After reading Joe’s article, I’m convinced.  If you believe that resource utilization is also a resource, and that implicit resource disposal (garbage collection) is the right default, then implicit cancellation is the only sane default.  In fact, we recently removed support for explicit cancellation, because we haven’t even ‘really’ used it yet.  (Some of Dusty’s code used it, but he said it was fine to take it out.)

We may have to implement explicit cancellation again someday, but now I’m happy to wait until there is a compelling use case.

2 thoughts on “Tasks, object lifetimes, and implicit cancellation”

  1. Wow, I actually understood what Chad was talking about. I suppose those two semesters of programming actually did sink in a bit. :P

Leave a Reply

Your email address will not be published. Required fields are marked *