On Thu, May 05, 2011 at 02:20:09AM -0400, Greg Stein wrote: > Ideally, the notification > process is fast, but somebody left a question of putting a cancel func > in that processing, and it sounded reasonable. We just don't know what > that callback is doing.
Why do we want to allow callbacks to do anything they want? What if the callback tries to do something that will result in a deadlock? Can't we document what the callback is allowed to do and what it isn't allowed to do? Even if descriptions end up being vague, like "this callback should complete fast"? Thinking about it I'm actually surprised that we're not doing this. I wonder how many times consumers of our APIs have been asking themselves questions about what they're allowed to do while implementing callbacks. I suppose the only place to find answers to such questions right now is our own code.
