id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
25	Move long scans to secondary threads	Gregg Young	Gregg Young	"The freeze occurred 
when FM/2 tried to scan a network drive that is setup using the netdrive 
samba plugin. Normally if it has problems it returns an error 65. However, 
the system the drive was on had locked up and when fm/2 scanned it the 
WPS froze and I had to kill FM/2. The only way I could reopen FM/2 was 
to exclude the 2 drives. After I rebooted the other machine all works fine. 
The WPS drives object opened without problem it showed the 2 netdrive 
drives as empty but no freeze occurred.  The same error message as below 
occurred again but I think the message was generated when I tried to kill 
FM/2 not when the freeze occurred.

Most of the scans that can take a long time are done on separate threads,
so this kind of failure will not lock up fm/2.  However, there are a few
that are still done on the PM thread and this can cause apparent Desktop
lockups.  If this is the case, pressing Ctrl-Esc several times should
cause PM to take control away from fm/2.

If we can identify what fm/2 was trying to do, we should be able to move
this logic to a thread.

The trap should not occur, even with slow access.  Unfortunately, the trap
is not within fm/2 code, so it's hard to analyze without a process dump. 
I will be adding exceptq support to fm/2, once I get some in-progress
exceptq rework completed.  This will provide enhanced trap logging,
without the need to resort to trap dumps.

The trap appears to somewhere in DOSREADASYNC or DOSWRITEASYNC, but that
does not tell us much about where and how fm/2 managed to pass bad
arguments to the API."	enhancement	closed	major	Release_3.14	fm/2 base		fixed	performance