There are two scenarios:
If the SynchronizationContext on the EasyDAClient object is null, then the events are raised on an internal thread (i.e. it is guaranteed it is not any of the other threads you have in your application). In such case, if you block in that thread, it does not affect those other threads; it only stops more notifications from coming. You may spin up new thread in this scenario, if you have a need for it - but you do not have to do it in other to keep the rest of your app performing well.
If the SynchronizationContext on the EasyDAClient is set to non-null, then the even notifications go through that SynchronizationContext object. What that means in relation to threads is up to the specific class of SynchronizationContext that is used. If, for example, your code is a Windows Forms application, and you set the SynchronizationContext to the current context when the form is initialized, then this particular SynchronizationContext for Windows Forms class guarantees that you will be able to manipulate controls on the form (which is otherwise not guaranted to work from just any generic thread - it must be the UI thread). In effect, however, this means that now the event notification is happening on the UI thread, and blocking in it will stop the other UI in your application. In this scenario, to prevent it, you would spin up a new thread to do the blocking work.
