Best practices for handling a Stalled thread

[Yaron 53]

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 December 21, 2019 by Yaron

[Rollo62 539]

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.

[aehimself 399]

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.

[David Heffernan 2353]

I would handle this by using screenshot code that did not hang. 

[Yaron 53]

@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 December 22, 2019 by Yaron

[Fr0sT.Brutal 900]

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" 😄

[Martin Wienold 35]

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 December 23, 2019 by Martin Wienold

[Fr0sT.Brutal 900]

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

[Martin Wienold 35]

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 December 24, 2019 by Martin Wienold

[Yaron 53]

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

 

[Fr0sT.Brutal 900]

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

[David Heffernan 2353]

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. 

[David Heffernan 2353]

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 December 24, 2019 by David Heffernan