Hanging network drives

[Hacker]

Sven,
Nice having you here. I wonder if you could help us with this problem http://ghisler.ch/board/viewtopic.php?t=2937 . Would be nice if you'd be willing to. I (and everyone) would of course understand if you wouldn't, too.

TIA
Roman

[Sven]

Sven,
Nice having you here. I wonder if you could help us with this problem http://ghisler.ch/board/viewtopic.php?t=2937 . Would be nice if you'd be willing to. I (and everyone) would of course understand if you wouldn't, too.

There is nothing special, SC only uses a background thread for accessing network folders.

[Hacker]

Hmm, in this thread - http://ghisler.ch/board/viewtopic.php?t=3051 , Christian is quoted as saying,
"...I was disappointed by Windows! Example: When I try to read a directory from a server on the net which has crashed, this will hang not only the current thread, but also all other threads of the same program which call any directory function, even with local folders - until the hanging connection times out! Yes, I tried all kinds of things to get rid of the thread when it was hanging (just ignoring the trhead, killing the thread), but unfortunately nothing worked."

How do you solve this?

Thanks
Roman

[SanskritFritz]

Hacker
That is a brave attempt, respect! If you pursuade Sven to help Christian, we will owe you a lot.
Sven, please...

[Sven]

Hmm, in this thread - http://ghisler.ch/board/viewtopic.php?t=3051 , Christian is quoted as saying,
"...I was disappointed by Windows! Example: When I try to read a directory from a server on the net which has crashed, this will hang not only the current thread, but also all other threads of the same program which call any directory function, even with local folders - until the hanging connection times out! Yes, I tried all kinds of things to get rid of the thread when it was hanging (just ignoring the trhead, killing the thread), but unfortunately nothing worked."

How do you solve this?

You will not believe me, but I can't duplicate this behaviour. As said before there is nothing special, SC uses only a background thread. However, it might be related to the development environment.

@SanskritFritz: Did you try SetToday? Was that the one you are looking for?

[ghisler(Author)]

You will not believe me, but I can't duplicate this behaviour. As said before there is nothing special, SC uses only a background thread.

Then what do you do when the user cancels the connection? I tried the following
- just let the thread run until it times out
- kill the thread

In both cases, thenext call to FindFirstFile blocked until the hanging thread had timed out, even when calling FindFirstFile with a local drive like c: . This happens on Windows 2000, which is advertised as a true multi-tasking operating system...

[SanskritFritz]

I guess from now on we will have both eyes on this thread... Sven PLEASE

[Sven]

Christian, I wrote a small sample (http://www.sp-download.de/plugins/CheckNetwork.zip), source and executable are included. To test it, open the DOS prompt and run CheckNetwork.exe with a UNC name which does not exist (for instance "\\ServerXXX\FolderXXX"). You can cancel the background thread with F10 or wait for a timeout. In either way the OS should not show any problems.

[SanskritFritz]

Is there any progress regarding this problem? Christian? Please? Pretty please?

[ghisler(Author)]

To Sven: My code looks almost exactly the same, except for the TerminateThread() call. I will try that. Thanks for your help!

[ghisler(Author)]

I just checked the Windows help and MSDN site, and found the following warning:

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. For example, TerminateThread can result in the following problems:

· If the target thread owns a critical section, the critical section will not be released.
· If the target thread is executing certain kernel32 calls when it is terminated, the kernel32 state for the thread's process could be inconsistent.
· If the target thread is manipulating the global state of a shared DLL, the state of the DLL could be destroyed, affecting other users of the DLL.

Therefore I don't know whether it's such a good idea to use TerminateThread: FindFirstFile is a Kernel32 call, and the above explicitly warns NOT to call TerminateThread during such a Kernel32 call, because the Kernel32 state for the entire process would become inconsistent. I also don't know whether the function currently uses a critical section. So even if it works fine on some Windows versions, it may cause damage on other versions.

What do you others think? Should I add it? Or is the risk too high?

[ghisler(Author)]

Me again: I checked again the code when I tried to add this feature: I did indeed try it with TerminateThread too, but subsequent FindFirstFile calls were also hanging even when using TerminateThread. Maybe Microsoft changed something in newer service pack versions, so I will re-try with that code...

[SanskritFritz]

Just a thought: I suppose you tried to rewrite Sven-s code in Delphi. What if Delphi causes the problem, maybe the IO API wrappers are not thread safe? Have you considered moving from Delphi 2 to higher versions?

[SanskritFritz]

And I also think Christian is using as few internal Delphi functions as possible, doing almost everything through the WinAPI

You are right, I just realized, that Christian wrote about calling FindFirstFile. That is a pure API call, with no wrapper around it. My mistake.

[ghisler(Author)]

Indeed I'm using pure API calls, not Delphi wrappers, so this cannot be the problem. Any thoughts about the risks of calling TerminateThread? When even Microsoft says that it is risky, it should better not be called, right?