Is it OK to ask handlers of my events return immediately?

Question

I am writing a .NET library. One of the classes has events a user of the library will need to subscribe to. Is it OK to ask implementations of handlers for these events return quickly? Or is this a common problem for which there is a common solution?

(It will no be fatal if the handler took long - but things start to wrong if their handler takes longer than about half a second - it is a networking library and peers connected will think this peer has dropped as the event is raised on the same thread for sending replies)

e.g.

public delegate void Ping();

class A
{
    /// <summary>
    /// If your handler doesn't return quickly... I am going to cry.
    /// </summary>
    public event Ping Ping;

    private void RaisePing() 
    {
         var handler = Ping;
         if(handler != null)
             handler();
    }

    // this is called several times a secound
    private void MainLoop()
    {
        if(something)
            RaisePing();

        // time important stuff - musn't take long to get here...
    }
}

Answer 1

Is it OK to ask handlers of my events return immediately?

Yes.

You should explicitly state in your documentation that the library will not work well if the subscribers do not return in a timely fashion.

You should not enforce it

Why? Because you are saying that you are developing a library. A library, as opposed to a framework, leaves the user in control. Hence it's the user decision to do what they want when they subscribe upon your events.

Enforcing handlers to be quick would just increase the complexity making the library harder to use. That's why I think it's better to be clear with the expectations and just refer the users to the documentation if they get problems thanks to their slow handlers.

Answer 2

If it is crucial for your code that the handlers return quickly, you should build it upon a structure that allows you to cancel a handler. As event handlers do not allow you to cancel the execution of a handler, e.g. by a timeout, you have the following options among others:

• Use event handlers and accept that you do not have any control about what the caller does. Of course you can ask the callers to return within a specific time frame, but you should be prepared that sometimes they will not. You could, however, structure your code so that the event handlers are called at a spot in your code that is not time critical (e.g. in your sample move "Time important stuff" in front of the raise) or use threads to allow for parallel execution.
• If you do not need the special characteristics of events (e.g. subscription model, subscription of multiple handlers), you can use an alternative approach that allows you to cancel the handler. Depending on the Framework version you use, an alternative might be to use a Task that a caller provides to your class similar to a callback function. Tasks allow you to Wait for a specific number of milliseconds for their completion.

Answer 3

Personally I think it is a bad idea - since Windows is not real-time operation system. In non real-time operation systems you can't count on some method executing 0.5 seconds.