我可以通过限制方法允许执行的时间来避免可能的挂起吗?
我正在使用外部 DLL (pdfsharp) 打开(然后操作)大量 PDF 文件。我使用:
Dim inputDocument = Pdf.IO.PdfReader.Open(PDFPath, IO.PdfDocumentOpenMode.ReadOnly)
问题是 - 它似乎挂在某些罕见的文件上。我似乎没有任何超时 - 它只是在这条线上挂了几个小时。我们用这个代码读取了数千个文件,总是在小文件上,所以我想一个快速的解决方法可能是在这个方法花费超过一两秒的时间时以某种方式超时。但我没有看到一个简单的方法来做到这一点。我希望避免旋转工作线程。
关于如何限制该线程允许的执行时间的任何想法,或者是否有更好(但简单)的方法?
I am using an external DLL (pdfsharp) to open (then manipulate) lots of PDF files. I use:
Dim inputDocument = Pdf.IO.PdfReader.Open(PDFPath, IO.PdfDocumentOpenMode.ReadOnly)
Problem is - it seems to hang on certain, rare files. I don't seem to get any timeout - it just hangs for hours on this line. We read thousands of files with this code, always on tiny files, so I was thinking that a quick workaround might be to somehow timeout if the this method takes more than a second or two. But I don't see a simple way to do this. I am hoping to avoid spinning up a worker thread.
Any thoughts on how I might limit this threads allowed execution time, or is there a better (but simple) way?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
Open() 调用不应挂起。绝不。如果您向我们提供了导致 Open() 挂起的文件,我们可以对此进行调查。
你的程序在服务器上运行吗?您使用 PDFsharp 的 DEBUG 版本吗?也许只是一个简单的 Debug.Assert() 被触发,但没有人能回答它。使用 RELEASE 构建可以解决这个问题。
The Open() call should not hang. Never. If you provide us with a file that causes Open() to hang, we can investigate this.
Does your program run on a server? Do you use a DEBUG build of PDFsharp? Maybe it's just a simple Debug.Assert() that is triggered, but noone can answer it. Using a RELEASE build would solve this.
我们最终通过创建 AbortableBackgroundWorker 解决了这个问题。我不确定这最终是谁的代码 - 但我们在网上找到了它并在这里分享。在极少数情况下,其中一个 PDF 挂起 PdfSharp Open() 调用,我们会中止后台工作程序。
We ended up working around this problem by creating an AbortableBackgroundWorker. I am not sure whose code this ended up being - but we found it online and sharing it here. In the rare case where one of the PDF's hangs the PdfSharp Open() call, we abort the background worker.