1

I'm using a VLC wrapper in C# to display video streams, my program has a list of video streams which it iterates through by calling the wrappers "playitem" method. After an unknown amount of time(and calls to playitem) the program hangs when the playitem method is called. There is no exception, and from what I can tell the wrapper(or underlying code) is waiting on some sort of resource to return before it proceeds(CPU usage stays the same).

I want to figure out when this method is taking too long to return and then bail out of the function call, that way I can drop whatever resources the wrapper is using and reload everything, all without killing the entire process. Is this possible? Is there a way to wrap a function call in some sort of timeout?

LightLabyrinth
  • 362
  • 3
  • 14
  • There's multiple strategies. The MSDN article [Cancellation in Managed Threads](http://msdn.microsoft.com/en-us/library/dd997364(v=vs.110).aspx) is worth reading. [Threading in C# by Joseph Albahari](http://www.albahari.com/threading/threading.pdf) has a short section on canceling a thread which may help. You could also use [WinDbg](http://blogs.msdn.com/b/msdnts/archive/2006/11/24/how-to-debug-application-crash-hang-in-production-environment.aspx) to determine what's causing the hang – Conrad Frix Jul 08 '14 at 21:00
  • What do you mean by `kill the VLC wrapper`? it is not a thread or process, just a class. So there is no such thing. – EZI Jul 08 '14 at 21:18
  • EZI - I mean dropping all resources held by the class. – LightLabyrinth Jul 09 '14 at 16:32

1 Answers1

2

You are not going to like what I am about to say. The only reliable way to cancel an operation in progress is to use cooperative cancellations techniques. This question already covers most scenarios so there is no need to rehash them here. Plus, they probably will not help you in this case anyway.

The problem is that you have a 3rd party API that, presumably anyway, does not offer any cancellation support. If that is the case then you really only have two options; only one of which is good.

Option 1: If the API is managed (running in the CLR) then you could put all of the calls to it in another thread and then abort the thread if it is misbehaving. It is a bad idea because aborting threads can lead to memory corruption. It might not work anyway because the CLR tries to inject aborts at potential safe points in the code. If the API is executing unmanaged code then the CLR may delay the abort until the execution returns back to the managed realm which will not happen if the call is hung.

Option 2: A better option to go with is to redesign your application so that there are two processes running. One would be the main part of the application and the other would act as a proxy for the 3rd party API calls. You would then use WCF (or whatever) to pass messages back and forth. If the API misbehaves and hangs then the main process will kill the child process and spin up a new one. The main process would be immune from the concerns of memory corruption because the API calls are isolated in their own process. It would be a lot of work to refactor your code to set this up correctly, but it is one of the few options that would actually be reliable.

Community
  • 1
  • 1
Brian Gideon
  • 47,849
  • 13
  • 107
  • 150