Questions you should ask before using a callback / delegate

re: Questions you should ask before using a callback / delegate

Mike Stall - MSFT — Tue, 17 Oct 2006 07:39:47 GMT

David - those are great defensive rules.

re: Questions you should ask before using a callback / delegate

David Levine — Tue, 17 Oct 2006 02:37:43 GMT

These are all very valuable questions that devs should ask when designing and implementing a callback of any type (delegates are one type).

I try to never make assumptions about what the callee will do in the callback. I assume that some piece of code somewhere will abuse the callback and leave me to try to pick up the pieces, so I try to program as defensively as possible. Many of my "golden rules" are similar to yours. This means...

1. All callbacks must be rentrant or handle reentrancy issues. For example, I always assume that a call to initiate another operation can occur within a completion routine.

2. I never call the callback with locks held. I've not run into a case where I needed to hold a lock - I've redesigned a few components to remove the need.

3. Always assume the callee will cause an error condition....so wrap your callback in a try-catch handler with suitable and well-defined error semantics (ignore/swallow, propagate, rethrow, crash, etc).

Associated questions are: if one callback raises an error how will that affect other subscribers to an event or callback? Does it cancel it? Abort it?

Are errors saved and reported elsewhere? Discarded? Logged? Traced?

4. Make no assumptions about thread state on return. Priorities may have changed, security contexts may be different, etc. This is similar to your example about static variables - it is state shared across instances. If global state is altered how should the caller react?

5. Make no assumptions about how long it will take the callee to complete and return, or what they will do in the callback routine. Also consider using asynchronous versus synchronous callback mechanisms - this may avoid running into some deadlock problems, especially when calling back into a UI thread.

6. I consider calling back using the original caller's synchronization context - this helps in situations where some callbacks occur on non-UI threads while others occur on UI threads. If its a UI thread I generally prefer to use async callbacks.

If you must constrain what the callback is allowed to do then it should be part of the intellisense documentation and well documented elsewhere so that devs that are otherwise unfamiliar with your component will have as good a chance as possible of understanding and programming against those constraints.

It would be nice if somehow the component itself could enforce the constraints that callbacks must adhere to, but I think we are lightyears away from such an environment.

re: Questions you should ask before using a callback / delegate

Kent Boogaart — Mon, 16 Oct 2006 06:17:01 GMT

Great post. Regarding the locking issues, I would argue that never taking a lock on a publicly accessible object is a good thing. If you need to share a lock amongst objects then you can expose a property / method to get / take the lock. That way you can control access to the lock.

I have long thought that .NET repeated a mistake made by platforms before it by allowing arbitrary locking on any object. IMHO, locks should only be permitted on a special purpose Lock struct / class. This would encourage encapsulation of locks and would have the added benefit of reducing the overhead associated with each object on the managed heap.

Interesting Finds: October 14, 2006

Jason Haley — Sat, 14 Oct 2006 23:29:55 GMT

re: Questions you should ask before using a callback / delegate

Peter Ritchie — Sat, 14 Oct 2006 17:18:14 GMT

Great post.

There's a thread on MSDN Forums that exemplifies another problem using asynchronous delegates when implicitly multithreaded: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=678862&SiteID=1. The gist is (one that you didn't mention) don't call Event-based Asynchronous Pattern asynchronous methods from an asynchronous delegate.