0

What is the best way to launch a hight-latency asynchronous IO operation (100ms-500ms average), where the IO operation does not have inherent APM or IO thread / completion port support?

I don't want to have threadpool / worker threads all being blocked by such an operation during bursts of activity.

My specific example case is with ODP.NET. It does not (yet?) support APM. I see this answer for how to handle that case, but I'm curious if that really is the generally-correct way to solve such a problem? I suppose it depends in part on the answer to this other question.

Community
  • 1
  • 1
Brent Arias
  • 29,277
  • 40
  • 133
  • 234
  • Is there any reason you can't have a pool of IO worker threads that *can* be blocked and reserver a different pool for general workers? – ssube Apr 30 '13 at 18:37

2 Answers2

2

If the IO operation has no inherent asynchronous support, and only supplies blocking methods for their operations, then you have no choice but to create a new thread or thread pool thread that just sits there waiting on it.

The only way around it is for the underlying IO operation to have asynchronous support.

Servy
  • 202,030
  • 26
  • 332
  • 449
1

In the case where it is absolutely impossible to rewrite with async IO, then your best choice is

(a) The ThreadPool but it will become sluggish when creating additional threads if you try to lease too many threads in one go. This in turn will affect the running of anything else that uses the ThreadPool... timers, that sort of thing... nasty.

(b) To use your own separate threadpool-like solution which doesn't suffer from this inherent limitation.

ThreadPool isn't really for blocking ops. I'd go for (b) if your concerns are realistic.

spender
  • 117,338
  • 33
  • 229
  • 351