Take it easy on the automatic retries

The Old New Thing : Just change that 15 to a 1

The Old New Thing : Just change that 15 to a 1 — Tue, 05 Sep 2006 17:01:58 GMT

PingBack from http://blogs.msdn.com/oldnewthing/archive/2006/09/05/741110.aspx

re: Take it easy on the automatic retries

BryanK — Thu, 17 Nov 2005 17:53:14 GMT

Nekto -- I would love to see that done (for one, it would mean you could install most patches without a reboot: the only updates that would require a reboot would be the ones that affect services or drivers that are required at all times by the kernel).

Unfortunately, I don't know how many programs use that (IMO mis-) feature as a way to do a lock-file with automatic clean-up (where if a process holds the lock-file and crashes, it'll get cleaned up the next time someone requests the lock). A change like that would break compatibility, which is extremely unfortunate.

re: Take it easy on the automatic retries

Nekto — Tue, 15 Nov 2005 18:39:29 GMT

"If I try to delete a file too quickly after closing the program that had the file open"

;)
The "best" solution whould be for DeleteFile function is to trace who is using file and find out if it trying to close itself. If yes - show message "Sorry we are waiting for that slow thing.." in notfication area. And to delete it after.
*joke*

What do you think about "unix way"? To delete file from list but not from disk until any handler exist and delete it only when that is freed. So user see file deleted instantly.

re: Take it easy on the automatic retries

Neil — Fri, 11 Nov 2005 19:52:44 GMT

Similarly I look at the files on a floppy before deciding I can format it (see later blog!) and of course the format fails because explorer has locked the drive...

Surely that "Deleting..." progress dialog should display while Explorer is retrying? Or maybe it does now, and I should upgrade.

re: Take it easy on the automatic retries

Dan — Wed, 09 Nov 2005 20:58:56 GMT

Ok - a bit off topic, but tangentially related to the retry delay on delete. When you are viewing a sub directory in an explorer window and right-click on a parent directory (in the folder list) and choose delete, you experience the delay while explorer retries deleting something that it has locked itself.

I can't tell you how many times I do this as it is so natural. You'd think I'd learn...

re: Take it easy on the automatic retries

Tim — Wed, 09 Nov 2005 18:47:05 GMT

"Sometimes it seems Microsoft uses the "compatability" excuse to avoid work."

Somewhere, Raymond's head is exploding :-D

re: Take it easy on the automatic retries

mirobin — Wed, 09 Nov 2005 10:20:11 GMT

Terminating a thread to abort an operation is never a safe thing to do, and is a good way to introduce a deadlock in your application. You have no idea what kind of resources/locks the thread you are terminating has a hold on (ex: the loader lock) when you yank the rug out, leading to unpredictable behavior later down the line.

At best, you would write the thread in such a manner that it could be abandoned by your application.

As far as the points the AC raises about retrying always being an unreliable solution, I would disagree to a point. If you expect that the application could take up to 5 seconds to shutdown, then yes retrying for 5 seconds is not reliable. If you expect that the *worst case* is that the application takes 5 seconds to shutdown then it is reliable.

re: Take it easy on the automatic retries

Derek — Wed, 09 Nov 2005 01:28:22 GMT

>I think the easiest solution to this problem is
>not to retry N times, but to retry for at most X
>seconds. That way you don't have to worry about
>how many times the layer below you has retried
>and retry delays won't be multiplicative.

The problem is that lower layers shouldn't be retrying at all. If you decide to retry for, say, 5 seconds, and the function you call decides to keep going for 3 years, what can you do about it? If the layer underneath doesn't have some sort of timeout functionality, you're just going to have to wait. You could create a second thread to monitor and kill the first thread if it takes too long but that's problematic because it's 1) way to complex a fix for something that shouldn't be happening at all, and 2) going to cause massive problems with resource leaks in the inknowingly-terminated thread.

re: Take it easy on the automatic retries

Anonymous Coward — Tue, 08 Nov 2005 23:49:00 GMT

As I said - if 4 retries are not sufficient, then 5 retries are no guarantee of success. The current system can *at best* mask problems up until something makes excel take 5.01 seconds instead of 4.99 seconds to release a file.

This means that scripts will fail erratically, not consistently, and if they're really that important then they damn well ought to be written by someone who's done more than read half way through "Learn Visual Basic For Applications in 21 Days". (Either that or the accountant writing scripts should quit whining when some coder who's read half of "Accounting For Dummies" thinks they know more about business management than the guy who spent 5 years at Harvard. Apparantly there's something in the water that makes people have no respect for any profession besides their own.)

Yeah, the current system can mask problems and make amateurs think that their badly written code is actually reliable. I'm not sure that's worth the irritaion of every user who gets an unresponsive user interface, but there's programers all over the world who'ld disagree with me.

re: Take it easy on the automatic retries

Cooney — Tue, 08 Nov 2005 23:34:01 GMT

> You'd be surprised how many scripts consist of replaying mouse clicks and keystrokes.

*shudder* Maybe not.