DonationCoder.com Software > Find And Run Robot

FARR hangs when %SPECIALSYS_DOCS% included in search folders

<< < (2/3) > >>

mouser:
See here for info: https://www.donationcoder.com/forum/index.php?topic=40658.0

The bug was that FARR normally is smart enough not to try to resolve network paths -- but a recent change resulted in it trying to resolve some, and this was frequently happening in the list of recently launched system files (which is what those %SPECIALSYS_DOCS% are).  Even if you don't have network mapped drives, it seems that some shortcuts (like the link to Steam) use a \\ network path.  This was causing the hang.

Shades:
Microsoft uses the guidelines for TCP/IP connections. That is, it will wait till 30 seconds (which feels a lot longer when you wait for something to happen on a computer) before it will give up on any network connection. This is part of a (sub-)set of parameters you can only change in the registry. MS doesn't have any window, field, picker, drop-down menu, check box or radio button for these parameters to be adjusted...on purpose.

The information is available on the MSDN/TechNet websites. Have found it there myself, but those settings can have serious implications, so I won't link to it either.

"Funny" thing is...if your application isn't multi-threaded and it tries to make a network connection it will wait 30 seconds before continuing, if the application needs to make another network connection, it will wait again for 30 seconds. This cycle is repeated every time for every network connection. The user gets the impression the application hangs, but in reality the application works like specified. It's the TCP/IP specifications that create the problem here.

skajfes:
Well, that has nothing to do with that. The application can hang for various reasons, usually it is either long running processes that take some time, or waiting on some resource (disk, network etc). You can't rely on the fact that IO (especially over the network) will work instantly, or reliably. The guideline is that your UI thread should never be doing any work, so that it remains responsive to the user. Any jobs (either long running or potentially on unreliable IO) should be running in a separate thread.

mouser:
Well what Shades said is related to what's causing the FARR delay; although FARR is multithreaded in some respects, it will hang while waiting trying to resolve network paths -- I need to make improve the multithreading to avoid that.

phitsc:
Fixed for me as well. Thanks :Thmbsup:

Navigation

[0] Message Index

[#] Next page

[*] Previous page