You can use a timer and periodically poll the datasocket, or, you can register a callback function that will be invoked when data is incoming over the datasocket.
If the "watching" application has a GUI, you can essentially idle by running the user interface - if the user doesn't do any GUI input, the application effectively idles, waiting for command input over your datasocket. If you don't have a GUI, you can have the "watching" application put itself to sleep and periodically wake up to process events, so that the callback function gets invoked if there's a command ready for it.
Or, you can have the watching application do a synchronous read on the datasocket with no timeout (or a long timeout) and that way the application suspends waiting for the read to complete when there's a command ready.
Is this a Windows application? If so, you can use a named pipe to do this - WinAPI named pipes have wait semantics on read that will do what I've described. Plus there's a message mode for the pipe that will cause a read to complete only when an entire message (command in your case) is ready, rather than an incoming byte stream.
If you don't like pipes you can use shared memory to move the commands between applications.
This is a lot of info to understand, but the bottom line is that it's possible to have two applications efficiently communicate synchronously.
