Avoiding hangs when calling a native API

Question

Background

We have a piece of programmable hardware here at work that we integrate into almost all of our systems. This piece of hardware came with a native Windows DLL (for which we do not have the source code) as well as a wrapper to said library. This wrapper is responsible only for marshalling the calls to the native API up to the .NET layer and nothing more. Therefore, we use this wrapper in order to make the calls to the native API.

This piece of programmable hardware is physically integrated into our product in a very problematic way. The piece of hardware sits in the product in such a way that every once in a while the USB cable gets cut in half... (don't ask) The problem is that the cable tends to get cut in half when we are deep into the native API. When this happens, the caller will not return from the native API function. Below is a snippet of what the call looks like via the wrapper:

    public static UInt32 Wrap(UInt32 configval, Int32 channum, IntPtr handleval)
    {
        if (IntPtr.Size == 4)
            return Native32(configval, channum, handleval);
        else
            return Native64(configval, channum, handleval);
    }

Question

Is there a general method of making sure we don't hang inside of the API?

I already know that I can just start a task, and wait for it with a timeout (just resume if it times out). This method works, but is there any other way of doing this? I have no control whatsoever of what goes on inside the API.

Answer 1

Basically the problem is blocking on a call that will never return. This is a solved problem in that every network call is highly likely to fail so we have things like sockets that have timeouts built-in to them. In one sense, the problem is that your code assumes this won't fail to respond when it can. The only way to get around that is to stop blocking on that call. You'll need some sort of asynchronous capability. Whether you use some sort of non-blocking IO or spawn a thread, the solution will have the same kind of high-level design.

The solution depends a lot on the overall architecture. If you are structured around a work-queue, then the nicest solution is when the API returns (or times out) you push the response to the work queue and deal with it. On the other hand, if your application is highly sequential, you probably have to block the main thread until the response comes back (or times out.)

In either approach, one issue is how long the API can be expected to take. If the response time is highly regular (low variance) then you can simply accept the timeout as a failure. If you can't put a reasonable upper-limit on the response time, you might want to take one more step on timeout to send another request to the API (preferably something fast) to check whether you are still connected. If you are still able to connect, the cord isn't cut and you can wait some more and repeat as necessary.

Answer 2

Since you're using .Net, why don't you put your call into a Task, with a timeout configured ? MSDN has a nice example about this, using Task.Wait:

https://msdn.microsoft.com/en-us/library/dd235606(v=vs.110).aspx

using System;
using System.Threading.Tasks;

public class Example
{
   public static void Main()
   {
      Task t = Task.Run( () => {
                            Random rnd = new Random();
                            long sum = 0;
                            int n = 5000000;
                            for (int ctr = 1; ctr <= n; ctr++) {
                               int number = rnd.Next(0, 101);
                               sum += number;
                            }
                            Console.WriteLine("Total:   {0:N0}", sum);
                            Console.WriteLine("Mean:    {0:N2}", sum/n);
                            Console.WriteLine("N:       {0:N0}", n);   
                         } );
     TimeSpan ts = TimeSpan.FromMilliseconds(150);
     if (! t.Wait(ts))
        Console.WriteLine("The timeout interval elapsed.");
   }
}
// The example displays output similar to the following:
//       Total:   50,015,714
//       Mean:    50.02
//       N:       1,000,000
// Or it displays the following output:
//      The timeout interval elapsed.

Answer 3

The only way to return control from a function call that never returns, is to watch it from the side and smack it if it doesn't respond quickly. There is no other way to get a non-returning call to return.

So a task would work, but if you want to isolate the issue, you could start a thread inside the wrapper to make the call, so the main wrapper method can then handle a timeout on the thread's response. This would make your .NET client code very easy - you make a call and it might return after 50ms with a "no data" response, at the expense of putting the async call inside the wrapper (which isn't too much trouble to be fair, start a thread and WaitForSingleObject on its handle and a timeout)

Answer 4

I've seen several solutions to this kind of problems, all involving separate processes, which are usually connected through pipes, or use the Microsoft AddIn Framework MAF. The last is somehow complex, with a ton of intermediate classes between the main and the isolated process, and it can't have a unique identifying name for the dependent process.

It seems the only option to deal with native components which have potentially severe bugs, such as

• not returning from a call (can also be handled on thread level)
• memory leaks
• severe runtime errors, leading to process termination

or where you have to bridge architecture gaps, such as 32bit DLL under 64bit .NET process.