• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 198
  • Last Modified:

How to provide timeout to a method call

I have an 3rd party API written in unmanaged C++ which is basically a proxy - it connects to an app server on the internet, receives data and raises events. My application (written in C#) uses this functionality through wrapper class written in managed C++.

Due to bugs in this API, I need to be able to detect if the call is stuck. Ideally, I would have something like this embedded in my wrapper class:

   res = TimedAPIMethod(parameters, timeout);
catch (MyTimeoutException *ex)
// timeout happened, do whatever is needed

where TimedAPIMethod calls API method and provides results or throws a custom exception
if it times out.

I looked into delegates and BeginInvoke/EndInvoke but it seems not to work for me as EndInvoke must be called and I'll get stuck again waiting for delegate to finish.

I had another app where this was handled through separate worker thread launch, for each API call, which would be terminated if not finished in specified time. This doesn't look satisfactory to me beacuse it is not cheap - depending on traffic on app server, various threads in client app might launch multiple calls to API methods per second.

I'd like to hear from anyone who faced similar problems - what did you try, what did you settle for, what are the performance issues if I did this or that.
  • 2
  • 2
1 Solution
in my opnion, unless your 3rd party api is asynchronous , you can't get a timeout exception when you call it.
even you has a working thread, it can't affect the thread you call your api.
you should use event or other method to resolve it.

although, maybe i have a acceptable solution for your problem.
1.define timer task or similar object, 1 task has a unique id and a timeout time(whatevet format)
2.create a task queue, FIFO(first in, first out)
3.create a working thread, to exam task queue.
4.when a new call made, create a new timer task , push to tail of queue.
5.for working thread, continuous check the task  head of queue, if timeout time > now, then wait.
if timeout time <= now, pop the head task, process timeout event, then check next task.

as a result, you can use a single thread to handle all system timeout,
we use this in telecom system for years, hope helpful:)
cxdoodAuthor Commented:
I don't know the details of API implementation but we can treat it as synchronous.

Though I appreciate your idea it would introduce more complexity than benefits to my app.

The way app works is really complicated - it performs live synchronization between remote server application and local SQL Server database. Due to the structure of API and different modes of operation API provides, it has to use two APIWrapper class instances in two different modes, and then use multiple threads for different message queues, because some messages require lenghty processing before insertion into database and some other, much more frequent, do not.

This limits my enthusiasm regarding use of class level (not-method-local) variables I might use to pass parameters to worker threads. After spending a lot of time tidying out the design, synchronization, corruption detection and like, I hit the last wall - the situation where my call to API method just hangs.

Now, my APIWrapper class has a LOT of methods. Modifying all these will definitely be a pain in the ass, and I am tempted to go the easy route of detecting which message pump thread in this particular application is stuck and recreating it. Before I do that, I wanted to see if anyone facing similar problem came up with a better idea, namely encapsulating this functionality in the API wrapper, and not modifying each and every application that relies on this API (and I have a LOT of these too :( ).

BTW, I saw a recently posted article here


that makes use of Begin/EndInvoke but I find it a bit suspicious, since everyone else says EndInvoke is a must. Anyone knows for sure if this can be done like this?
from my own understanding, begin/end invoke just a .net warper, one working thread, and another thread waiting for
 complete/timeout signal(invoked by WaitHandle.WaitOne).
that's why you should use EndInvoke to wait working thread to finish , or it will cause unpredictable problems.
although the cost is not cheep, maybe you can try callback delegete instead of directly using EndInvoke in main thread,
or create a new thread to hang by EndInvoke:)
at least, your main thread won't block by it~
cxdoodAuthor Commented:

I did some more research on the issue, and after this


it seems that there is practically no way to safely kill a thread stuck in unmanaged call. Guess I'll just have to create a watchdog app and restart the whole app that times out.

Oh well.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: Amazon Web Services - Basic

Are you thinking about creating an Amazon Web Services account for your business? Not sure where to start? In this course you’ll get an overview of the history of AWS and take a tour of their user interface.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now