On Fri, 28 Mar 2014 14:29:55 GMT, Luca Niccoli wrote:

On Thu, 27 Mar 2014 14:30:18 GMT, Sönke Ludwig wrote:

Yes, this is what I had in mind, too. The only change I'd make is to wrap the Task in a private struct type, so that it can't interfere with user messages.

I submitted a pull request using Typedef!Task as an opaque type.

Hmm, FieldTypeTuple!T should not fall in that branch, but rather go as isWeaklyIsolated!(FieldTypeTuple!(T)[0], FieldTypeTuple!(T)[1], ...). If that's not the case, there is definitely a bug. But what I meant was that the compiler crashes instead of outputting an error message (assuming that there actually is an error).

ManualEvent is an interface, not a struct, class or union, so according to the documentation FieldTypeTuple!ManualEvent returns a tuple with a single element, ManualEvent. I think the infinite recursion is legitimate.
I submitted a pull request for isWeaklyIsolated and a bug report to dmd ( https://d.puremagic.com/issues/show_bug.cgi?id=12487 ) for the template infinite recursion.

Yeah, some testing would be good. Basically what is needed is as many threads as the number of I/O devices that is accessed in parallel. I wouldn't go for something too fancy here, though, because the plan is eventually to use asynchronous I/O here, too, on all platforms. But keeping the number of threads configurable is trivial, so that will be a good idea in any case.

Unfortunately asynchronous disk I/O seems to be in a very sorry state on many platforms (see for example http://blog.libtorrent.org/2012/10/asynchronous-disk-io/ ), so threaded I/O could remain a very useful fallback.

Thanks a lot for preparing the pull requests and I agree with regards to the threaded disk I/O. That blog post surely looks discouraging regarding Linux AIO. Fortunately, at least using overlapped I/O on Windows works and is already implemented.