How do I wait until a console application is idle?

问题:

I have a console application that starts up, hosts a bunch of services (long-running startup), and then waits for clients to call into it. I have integration tests that start this console application and make "client" calls. How do I wait for the console application to complete its startup before making the client calls?

I want to avoid doing Thread.Sleep(int) because that's dependent on the startup time (which may change) and I waste time if the startup is faster.

Process.WaitForInputIdle works only on applications with a UI (and I confirmed that it does throw an exception in this case).

I'm open to awkward solutions like, have the console application write a temp file when it's ready.

回答1:

One option would be to create a named EventWaitHandle. This creates a synchronization object that you can use across processes. Then you have your 'client' applications wait until the event is signalled before proceeding. Once the main console application has completed the startup it can signal the event.

http://msdn.microsoft.com/en-us/library/41acw8ct(VS.80).aspx

As an example, your "Server" console application might have the following. This is not compiled so it is just a starting point :)

using System.Threading;
static EventWaitHandle _startedEvent;
static void main()
{  
  _startedEvent = new EventWaitHandle(false, EventResetMode.ManualReset, @"Global\ConServerStarted");

  DoLongRunnningInitialization();

  // Signal the event so that all the waiting clients can proceed
  _startedEvent.Set();
}

The clients would then be doing something like this

using System.Threading;
static void main()
{  
  EventWaitHandle startedEvent = new EventWaitHandle(false, EventResetMode.ManualReset, @"Global\ConServerStarted");

  // Wait for the event to be signaled, if it is already signalled then this will fall throught immediately.
  startedEvent.WaitOne();    

//  ... continue communicating with the server console app now ...
}

回答2:

What about setting a mutex, and removing it once start up is done. Have the client app wait until it can grab the mutex before it starts doing things.

回答3:

Include an is ready check in the app's client interface, or have it return a not ready error if called before it's ready.

回答4:

Create a WCF service that you can use for querying the status of the server process. Only start this service if a particular command is passed on the command line. The following traits will ensure a very fast startup of this service:

• Host this service as the first operation of the client application
• Use the net.tcp or net.pipe binding because they start very quickly
• Keep this service as simple as possible to ensure that as long as the console application doesn't terminate, it will remain available

The test runner can attempt to connect to this service. Retry the attempt if it fails until the console application terminates or a reasonably short timeout period expires. As long as the console application doesn't terminate unexpectedly you can rely on this service to provide any additional information before starting your tests in a reasonably short period of time.

回答5:

• Since the two(the console application, and integration test app that makes client calls - as I understand) are separate application, so there should be a mechanism - a bridge - that would tell play as a mediator(socket, external file, registry, etc).

• Another possibility could be that you come up with an average time the console takes to load the services and use that time in your test app; well, just thinking out loud!