Jump to content
Yaron

Best practices for handling a Stalled thread

Recommended Posts

I have a usage case where my application scrapes a screenshot (thumbnail) from multiple video files in background threads.

I grab the screenshot using a third party library.

 

The problem is sometimes, the third party library will stall, usually due to a corrupt/incomplete media file where it tries to analyze the entire file (which can take upto 30 seconds).

I have no way to notify the third party library to cease operations.

 

This stalling can prevent my application from closing (It's waiting for threads to finish so the exit is clean) or even make the UI appear semi-broken because no thumbnails show up.

 

I'd like to hear what you may have done to handle such cases?

Edited by Yaron

Share this post


Link to post

Do you have sources of 3rd party, to find out if there is an endless loop somewhere.

I would always try to find that root cause first, before trying to kill running threads.

To kill a thread is also not a good idea IMHO.

Share this post


Link to post

Killing a thread is not a good idea in about 99% of the times 🙂 The best case is that it will leak memory and / or abandon TCP connections.

Worst case? It can leave corrupted temporary files around, render your application unusable and requiring a restart or even leave the system in an unbootable state (depending what it is doing which gets forcefully interrupted).

 

Sometimes you have no other option though... 

 

 

There are some REALLY good advices there. Maybe you can launch the image processing in a child process - in regards to the host applications state killing a process can be less painful than a killing a thread.

  • Like 1

Share this post


Link to post

@David Heffernan It's not that the code freezes forever, it stalls.

 

Here are real-world examples,

1. A 3rd party product called ODB Studios has a bug, it does not set a timestamp for it's audio stream, so when playing a video, the entire stream must be decoded to reach the seek point (the position where I take the thumbnail).

This causes the (directshow) seek command to stall for upto 60 seconds.

 

2. A user starts to download a video file and then pauses/stops the download (so the file is no longer locked, I postpone thumbnail generation for locked files).

The video's frame-index block did not download yet, so the (directshow) file parser then scans the entire media file to reconstruct the frame-index which can easily stall for 30-60 seconds on multi-GB files.

 

There are other cases where this issue can happen, there is no way to avoid it since I can't know in advance every case for every audio/video format that may pop-up.

 

 

Edited by Yaron

Share this post


Link to post

In your case I see no problems. If you're closing your app, just terminate the stalled threads. From what you said, they only do reading so no junk files remain and all handles/memory/resources will be freed on app close. If you're not closing the app, let the thread do its job; just show some progress mark. Maybe even mention that long operation isn't your app's fault, like "Doing my best to reconstruct index of a broken, shitty-formatted file that you've feed to me" 😄

Share this post


Link to post

Do not terminate a Thread as it may lead to all kind of strange behaviour.

MSDN: TerminateThread function

Quote

TerminateThread is a dangerous function that should only be used in the most extreme cases. You should call TerminateThread only if you know exactly what the target thread is doing, and you control all of the code that the target thread could possibly be running at the time of the termination.

 

You could explore refactoring the logic of your thread into a small exe and call this instead, if this one stalls you can terminate its process.

Edited by Martin Wienold

Share this post


Link to post
1 hour ago, Martin Wienold said:

Do not terminate a Thread as it may lead to all kind of strange behaviour.

MSDN: TerminateThread function

 

You could explore refactoring the logic of your thread into a small exe and call this instead, if this one stalls you can terminate its process.

If the main app is closing, terminating a thread doesn't differ much from terminating a process. So in this very case, this function could be used

Share this post


Link to post

The difference is that terminating a process does not affect your current process from which you are calling the termination.

Terminating a thread has the posibility to do just that, it may corrupt the process memory you are running it in. (This heavily depends on what is going on in the thread you are terminating and your gues is as good as mine)

 

As this thread asked for best practice for what to do with a stalled thread:

Do nothing, let it finish or try to build in a way for it to eventually finish without terminating it.

If this is not a possibility and you just have to have a way to end it forcefully, let it run in a different process, isolated from your own.

Edited by Martin Wienold
  • Like 1

Share this post


Link to post

I can attest from experience that terminating threads can lead to random access violations, that's part of the reason I asked this question.

 

Share this post


Link to post
1 hour ago, Yaron said:

I can attest from experience that terminating threads can lead to random access violations, that's part of the reason I asked this question.

 

This strongly depends on what is being done in these threads

Share this post


Link to post
On 12/23/2019 at 11:26 AM, Fr0sT.Brutal said:

If the main app is closing, terminating a thread doesn't differ much from terminating a process. So in this very case, this function could be used

Not so. You are just as likely to have subsequent errors as the shutdown code in the main thread runs. 

Share this post


Link to post
6 hours ago, Yaron said:

I can attest from experience that terminating threads can lead to random access violations, that's part of the reason I asked this question.

 

If you want to terminate the process, terminate the process. Ignore the threads. System will tidy up all the resources, including the threads. Let it do it though, don't you try. 

 

ExitProcess does the job. 

Edited by David Heffernan

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×