FileSystemWatcher .Net 3.5

Question

刚刚从.Net 1.1切换到3.5 on Win服务，活跃了10年，处理了200多万个文件。我有一个异步类，它使用FileSystemWatcher事件处理程序将图形打印到PDFPrinter，现在在它自己的STA线程上，归档PDF文件。PDF创建是异步的，因为现有的客户端应用程序方法允许在DateTime间隔中创建所有丢失的PDF。

(1)如果STA线程上没有剥离事件处理程序，服务将挂起。

(2)在几秒钟内只有几个PDF到达的情况下，它工作得很好。将其增加到5个PDF，不可避免地会有一个文件无法存档。将其增加到15个PDF，其中几个不会存档(所有这些都是在测试床上进行的)。在移动文件之前，我会检查它是否存在，这需要两次成功的检测(PDFPrinters往往会产生幻象文件创建事件)。我还检查对该文件的独占访问权限。更新:我在COM交互代码的不同部分尝试了另一种STA线程创建方法(通过参数化的类和方法)，遇到了同样的不可靠问题(只有大约50%的线程完成)。

对于PDF，我很想设置一个定时器来归档被遗弃的文件，但我不知道何时启动定时器，以避免多个定时器尝试执行相同的归档任务(同时还存在Oracle并发问题的风险)；这种设计感觉有点像皮带和吊带(负面因素)。

这是一个很常见的范例，让它变得健壮应该不是那么困难！在(1)上寻找启示，并帮助使新的STA线程可靠地完成(2)。

伪码

Test bed user interface:
    // Process 20 instrument raw data files in a loop
    // For each file:
    // 1-2 s to setup processing and retrieve metadata from database on each file
    // (A) spin off STA worker thread
    // call instrument vendor COM API to read data file
    // setup FileSystemWatcher for PDF files
    // create graphical image PDF
    // handle PDF_Created in a shell that ...
    // (B) spins off STA worker thread to 
    // archive the PDF

Answer 1

回答(2)：我必须添加代码来线性化新的STA线程或将新的STA线程与旧的MTA线程重新同步(例如，阻止父线程，直到工作线程完成)。

thread.Join();

这在伪代码中的点(A)处工作得很好，但在点(B)处工作得很好，在那里我有一些共享的字段变量，这些变量仍然需要移动到线程参数中(可能是因为不是所有的PDF都被创建)

我承认我仍然不理解为什么在网络上归档文件的FileSystemWatcher需要在STA线程上处理(问题(1))。