How to handle starting/stopping API interface that may take a long time to start

Question

I have an application that needs to work with a vendor-supplied API to do Screen Pops when a call is routed to the user's extension. Another developer worked on getting the API to work and delivered a prototype wrapper class that isn't quite right, and I'm trying to get it right.

Because this API can block for several minutes before returning, the developer started the API interface code in a separate thread, like this:

// constructor
public ScreenPop( ...params... )
{
  ...
t = new Thread( StartInBackground );
t.Start();
)

private void StartInBackground()
{
  _listener = new ScreenPopTelephoneListener();
  _bAllocated = true;
  _listener.Initialize( _address );
  _bInitialized = true;
  _listener.StartListening( _extension );
  _bListening = true;
}

The call to Initialize is the one that could hang, if the phone server was unresponsive.

I don't think it was intentional on the part of the developer who did this, but when the API is initialized this way, the thread keeps running, so that now I have to stop the thread before I can clean up when I want to. I also have to use Invoke to get events from the thread, as others so kindly pointed out in my previous question, but that is working now.

Anyway, here is the logic used to shut everything down and clean up:

public void ShutdownFunc()
{
  try
  {
    if ( _bListening )
    {
      _listener.StopListening();
      _bListening = false;
    }
    if ( _bInitialized )
    {
      _listener.Shutdown();
      _bInitialized = false;
    }
    if ( _bAllocated )
    {
      _listener = null;
      _bAllocated = false;
    }
  }
}

Of course, there is a try/catch around the whole mess to prevent unhandled exceptions.

My biggest problem is, how do I call the shutdown code when the API interface code is running in a separate thread? I need to clean up in case the user logs off and then logs back on again, as the API gets confused if I don't. Thread.Abort won't work, as it's not in a place to catch the exception, and the "volatile bool" method won't work either, for obvious reasons (most of the time, the API thread is not active).

So there seems to be no way to call the shutdown logic if the API interface code is running on a separate thread. Thread.Abort() bypasses all the logic and kills the thread without cleaning up. Calling the shutdown logic from the GUI thread hangs when it calls the Shutdown method. So, what can I do?

The IDispose interface just adds another layer of abstraction in the GUI thread, and does nothing to solve the problem here.

For now, to get the rest of the code developed, I am eliminating threads completely. But, before I release the app, I need to figure this out.

Anybody?

Thanks,
Dave

Answer 1

You may further encapsulate initialization logic and check on a ManualResetEvent in the main initialization thread while spawning a worker thread to do the actual initialization. If the ManualResetEvent is set from your main thread while you're still initializing, you can abort the thread doing the actual initialization and do your cleanup, otherwise if the worker thread completes you just stop waiting on the ManualResetEvent. It's kind of dirty and tricky, but should do what it's supposed to ;)

Answer 2

First of all, if you need to shut down your application and Initialize() is still running, you have only two options:

1. Wait for 'Initialize' to finish
2. Abort the thread that's running 'Initialize'.

Aborting the thread should always be the last option, but in case you really need to stop the application and the Initialize doesn't have a timeout parameter, there's no other way.

Also, I would suggest wrapping that 3rd party API in your own class, implementing IDisposable on it and holding the API state using some enum instead of separate bool flags like you did in ShutdownFunc. Add some simple automation machine logic into it to handle each state. And keep the possible states count to minimum needed.

Or maybe throwing that vendor's library in the garbage can ;)

Answer 3

I reworked the logic for the shutdown function, to get rid of the handful of booleans floating around. Here's what the new code looks like:

private enum ApiState { Unallocated, Allocated, Initialized, Listening };
private ApiState _apiState = ApiState.Unallocated;

private void StartInBackground()
{
  _listener = new ScreenPopTelephoneListener();
  _apiState = ApiState.Allocated;
  _phoneListener.Initialize( _strAddress );
  _apiState = ApiState.Initialized;
  _phoneListener.StartListening( _intExtension.ToString() );
  _apiState = ApiState.Listening;
}

public void ShutdownFunc
{
  try
  {
    if ( ApiState.Listening == _apiState )
    {
      _listener.StopListening();
      _listener.Shutdown();
    }
    if ( ApiState.Initialized == _apiState )
    {
      _listener.Shutdown();
    }
  }
  catch {}
  finally
  {
    _listener = null;
    _apiState = ApiState.Unallocated;
  }
}

The problem remains, however, where I can't call the Shutdown logic without hanging the GUI thread. Is there any way to interrupt the worker thread using a call from the GUI thread, short of Abort? Can I possibly set up an event handler and use a manually generated event from the GUI thread to stop the worker thread? Has anyone tried this?

I haven't tried the suggestions regarding starting a new thread for the Initialization call, as that only solves part of the problem and may be unnecessary once I get the real problem resolved.

Answer 4

OK, here goes another attempt. I tried to declare an event and raise that event on the thread, to run the shutdown logic from the thread the API is running on. No luck, it still tries to run the shutdown logic on the GUI thread and hangs the application.

Here's the applicable code:

public delegate void HiPathScreenPop_ShutdownEventHandler( object parent );

class HiPathScreenPop
{
    // Shutdown event, raised to terminate API running in separate thread
    public event HiPathScreenPop_ShutdownEventHandler Shutdown;
    private Thread _th;

    //ctor
    public HiPathScreenPop()
    {
        ...
        _th = new Thread( StartInBackground );
        _th.Start();
    }

    private void StartInBackground()
    {
        _phoneListener = new ScreenPopTelephoneListener();
        _apiState = ApiState.Allocated;

        _phoneListener.StatusChanged += new _IScreenPopTelephoneListenerEvents_StatusChangedEventHandler( StatusChangedEvent );
        _phoneListener.ScreenPop += new _IScreenPopTelephoneListenerEvents_ScreenPopEventHandler( ScreenPopEvent );
        this.Shutdown += new HiPathScreenPop_ShutdownEventHandler( HiPathScreenPop_Shutdown );

        _phoneListener.Initialize( _strAddress );
        _apiState = ApiState.Initialized;

        _phoneListener.StartListening( _intExtension.ToString() );
        _apiState = ApiState.Listening;
    }

    public void KillListener()
    {
        OnShutdown();
    }

    private void OnShutdown()
    {
        if ( this.Shutdown != null )
        {
            this.Shutdown( this );
        }
    }

    void HiPathScreenPop_Shutdown( object parent )
    {
        // code from previous posts
    }
}

What seems to happen when I call KillListener is this:

1) OnShutdown() gets called on the UI thread (OK)

2) Shutdown( this ) gets called (here's where I expect an event to be raised ont the background thread

3) HiPathScreenPop_Shutdown() gets called on the UI thread, and hangs on the _phoneListener.ShutDown() call, same as if I was not using the event mechanism.

OK, so what piece(s) of magic am I missing, or completely misunderstanding? It seems all the plumbing I created did nothing much except clutter up the code...

Thanks for any reponses, Dave

Answer 5

When you call an event handler directly from Thread A, all the handlers for that event are also executed on Thread A. There is no way to inject that handler into your other thread. You could spawn another thread to run Shutdown, but this still doesn't solve the problem of Initialize not being finished yet - it just moves the problem yet again. It does let you display a waiting dialog for the user.

Ultimately if this line of code hangs for a while:

_phoneListener.Initialize( _strAddress );

then there's nothing you can really do apart from wait for that to finish (either on the UI thread or in another thread with some form of waiting UI) and have a check after that call that causes the handler thread to exit.

_phoneListener.Initialize( _strAddress );
if (_exit.WaitOne(0))
{
    return;
}

In your main shutdown routine you want something like:

_exit.Set();
_th.Join();

// Rest of cleanup code

This will then wait for the thread to exit. I wouldn't recommend calling Abort on a thread ever, as you have no idea what will happen to any state that thread was referencing. If you have to Abort a thread then plan on restarting the whole application to be safe.

Answer 6

With the help of a fellow developer here, I was able to get the code working as desired. What I needed to do was take everything out of the thread except the call to Initialize(), so that the API instance was not running on a separate thread. I then had a different problem, as the status was set from 2 different threads and was not what I expected it to be when I went to clean up.

Here is the final solution:

// declare a background worker to init the API
private BackgroundWorker _bgWorker;

// ctor
public HiPathScreenPop( ... )
{
    ...

    _phoneListener = new ScreenPopTelephoneListener();
    _apiState = ApiState.Allocated;

    _phoneListener.StatusChanged += new _IScreenPopTelephoneListenerEvents_StatusChangedEventHandler( StatusChangedEvent );
    _phoneListener.ScreenPop += new _IScreenPopTelephoneListenerEvents_ScreenPopEventHandler( ScreenPopEvent );

    _bgWorker = new BackgroundWorker();
    _bgWorker.DoWork += new DoWorkEventHandler(StartInBackground);
    _bgWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler( bgWorker_RunWorkerCompleted );

    _bgWorker.RunWorkerAsync();
}

 void _bgWorker_DoWork( object sender, DoWorkEventArgs e )
{
    _phoneListener.Initialize( _strAddress );
}

void bgWorker_RunWorkerCompleted( object sender, RunWorkerCompletedEventArgs e )
{
    _apiState = ApiState.Initialized;  // probably not necessary...

    _phoneListener.StartListening( _intExtension.ToString() );
    _apiState = ApiState.Listening;
}

Now, the API instance is running in the same thread as the UI and everybody's happy. The call to Shutdwn() no longer hangs, I don't need Invoke() for the callbacks, and the long-running code executes in a background worker thread.

What this code does not show are the great ideas presented earlier for how to handle the case where the user shuts down before the call to Initialize() returns. The final code will be a synthesis of these solutions.

Thanks to all for the great feedback!

Dave