Link.Break and the FileSystemWatcher

[aplteam]

Describe the bug

When I break a Link, shouldn't Link kill the threads running the FileSystemWatcher?

What I did:

      ]link.Break #.Cider
Unlinked: #.Cider
      )save
Cannot perform operation with threads running.
     ]link.status
No active links
      )si
·   ⎕SE.Link.Watcher.WatchEvent[5]
·   System.IO.FileSystemWatcher.OnChanged[]
·   System.IO.FileSystemWatcher.NotifyFileSystemEventArgs[]
·   System.IO.FileSystemWatcher.CompletionStatusChanged[]
·   System.Threading._IOCompletionCallback.PerformIOCompletionCallback[]
&285 (system thread:29768)
·   ⎕SE.Link.Watcher.DisposeFSW[6]
&286 (system thread:1804)   

     ]tools.Version
 Dyalog  18.2.47418 32-bit Unicode, BuildID c8e80564            
 OS      Windows 10 or Windows Server 2016 (10.0.19045) 32-bit  
 Link    3.0.19                                                 
 SALT    2.9                                                    
 UCMD    2.51                                                   
 .NET    .NET Framework 4.8.9181.0                              
 Tatin   0.103.1                                                
 Cider   0.38.0                                                 
 WS      18.2                                                   

For the record: my <02139>

[mkromberg]

There are no "threads running the file system watcher", threads are created to handle FSW events as they are generated by instances FSW objects. In this case, it looks like the bit of code that is supposed to get rid of the FSW (Watcher.DisposeFSW) is hanging on the .Net call to the Dispose method. If you are able to reproduce this, I'm keen to take a look.

[aplteam]

I led a function doing the critical steps in an endless loop but gave up after 100,000 laps.

However, I've seen this before, so it's a problem that shows every now and then.