Question

This is a question about generic c++ event driven applications design.
Lets assume that we have two threads, a “Dispatcher” (or “Engine”…) and a “Listener” (or “Client”…).

Let’s assume that I write the Dispatcher code, and release it as a library. I also write the Listener interface, of course.
When the Dispatcher executes (after Listener registration)


listenerInstance.onSomeEvent();


the event handling code will actually be executed by the Dispatcher thread, so if the person that implements the Listener writes something like


void Listener::onSomeEvent() { while(true) ; }


The Dispatcher will stuck forever.

Is there a “plain old c++” (I mean no boost or libsigc++) way to “decouple” the two classes, so I can be sure that my Dispatcher will work fine whatever the Listeners does in the callbacks?

bye and thanks in advance,
Andrea

Answer 1

Well if the event gets invoked in the same thread (as I seem to understand can be a requirement), then there isn’t much you can do about it.

If this is under a Win32 app with a message pump, you could register a windows message and call PostMessage with data representing this event and you can patch the message loop to interpret that message and call the event. What you gain is a decoupling of sorts, the event call is asynchronous (ie the event call will return no matter what). But later on when you process your messages and actually call the event, your main thread will still be stalled and nothing else will run until the event handler is ready.

Another alternative is just creating a new thread (or using a thread pool) for your call. This won’t work for events that require a certain thread (ie ui updating threads). Additionally this adds synchronization overhead and thread spawning overhead AND you might starve the system of threads and/or cpu time.

But really, I don’t think it’s your job as the library designer to anticipate and avoid these problems. If the end-user wants to create a long event handler, let him spawn a new thread on his own. If he doesn’t and just wants his specific thread to handle an event, let him. It simplifies your job and doesn’t add any overhead that’s not needed.