Use of Escape to cancel USB transfers

What are people’s thoughts on this?

At the moment Escape can be used to break out of the tsleep() function, which should have the affect of aborting any wait condition and returning control to the user. Except:

• I don’t think that all of the USB stack handles the abort correctly (the transfer will be left in the USBD_IN_PROGRESS state, which code won’t expect if tsleep() was called without a timeout specified)
• Most of the time the user will be in the desktop (where the Escape key won’t be enabled, rendering the code useless as a means to escape any misbehaving code)
• No consideration is given as to how long the transfer has been running for. E.g. if a big bulk transfer is in progress, and then another driver initiaites a control transfer (which is always performed in a blocking manner and should complete immediately) then by pressing escape there’s a chance you’ll end up cancelling the control transfer instead of the bulk one, potentially breaking a device which wasn’t misbehaving in any way.
• Last night I was doing some tests with the command-line unzip tool running from a taskwindow. I started it running, then realised that enabling quiet mode would make it go faster. So I pressed escape a couple of times, and it looks like I managed to cancel one of the USB transfers – except this transfer was initiated by SCSISoftUSB, and the SCSI/filesystem stack didn’t cope with the error properly. A couple of Wimp error boxes appeared and the unzip tool kept running, except it was complaining about corrupt data. After stopping the tool I then found that the drive the zipfile was on had been left in an inconsistent state – it seemed like commands that referenced the drive by number worked, but commands that referenced it by name failed (although curiously I could still refresh the filer window, which contains the drive name in the title). Dismounting and replugging the drive resulted in the dreaded ‘ambiguous disc name’ error, so I had to reboot to get it working again.

So can anyone offer any compelling reason why we should allow Escape to cancel calls to tsleep()? As far as I can tell all it will do is cause us trouble, or have no beneficial effect whatsoever if the user is running ordinary programs in the Wimp. At the least, if we are going to allow it, we should really follow the lead of something like ShareFS, which (IIRC) waits for a few seconds and then shows the hourglass and starts checking for Escape.

Also I suspect we should probably look into whatever went wrong in the SCSI stack, to work out what it thought went wrong and why it failed to recover the drive (or failed to dismount it properly if it thought the drive was completely broken)

When I read the thread’s title, my first thought was that you were thinking of adding the ability to use Escape to cancel transfers, and my immediate thought was that that would cause chaos. I couldn’t see how it could be made to work.

I agree with all your misgivings, and I think the Escape cancel mechanism should be removed.

I think that looks like early debugging functionality and should be removed.

A few days ago I finally checked in some changes to get rid of the code which allows USB transfers to be cancelled via Escape.

I suppose if we really did want the ability to cancel transfers via Escape, then it should be a flag that gets set on a per-transfer/per-pipe basis, instead of just a global thing like it was originally.