Multi-threading for network drives?

Features wanted...
Post Reply
tim11g
Posts: 19
Joined: 06 Jan 2021 15:38

Multi-threading for network drives?

Post by tim11g »

This is an issue for many Windows programs including XY
Suppose XY has a tab referencing a folder on a network share, and that server has become unavailable since the last time it was accessed.
If the user then clicks on the tab or a file in the folder, XY will become completely unresponsive and unusable for about 60 seconds until something times out.
Could the "network call" that causes the application-level blocking be moved into another thread so the rest of the application can still be usable?

tim11g
Posts: 19
Joined: 06 Jan 2021 15:38

Re: Multi-threading for network drives?

Post by tim11g »

Are there any workarounds for this behavior? Can these extremely long timeouts (which were probably necessary in the days of ISDN and frame relay WANs) be reduced? Is there any way to keep XY from locking up (application modal blocking) during the extended network timeout?

bvdbos
Posts: 1
Joined: 17 Jun 2021 20:32

Re: Multi-threading for network drives?

Post by bvdbos »

Isn't this the same as viewtopic.php?f=2&t=21757&start=30 ?

tim11g
Posts: 19
Joined: 06 Jan 2021 15:38

Re: Multi-threading for network drives?

Post by tim11g »

bvdbos wrote: 17 Jun 2021 20:34 Isn't this the same as viewtopic.php?f=2&t=21757&start=30 ?
I don't think so --- the other thread is about a delay before an ultimately successful connection to a network resource.
I'm talking about the specific case of the network resource becoming unavailable since it was last accessed in XY, while the tab remains open. This results in a 60 second application-modal freeze in XY when the tab is next touched.


Side note - searching on "netsh interface tcp set global autotuning=disabled" brings up articles with varying opinions, with some disputing benefits from disabling autotuning. Enabling aututuning means Windows uses the RFC 1323 standard, which enables "a set of TCP extensions to improve performance over large bandwidth*delay product paths and to provide reliable operation over very high-speed paths."

Microsoft says "When the Receive Window Auto-Tuning feature is enabled for HTTP traffic, older routers, older firewalls, and older operating systems that are incompatible with the Receive Window Auto-Tuning feature may sometimes cause slow data transfer or a loss of connectivity". It seems to be an external network issue, not an application issue.

Maybe disabling autotuning can provide benefit in some specific cases, but it might also be a case of the medicine being worse than the disease, from an overall system performance perspective. Especially if your network environment has the characteristics that RFC1323 was created to address.

Post Reply