Josh Simmons wrote: > >Not sure why we're evaluating disk access performance patterns when >dealing with network throughput which is only copying the data from >userspace to a kernel buffer provided you're using a proper async >socket access pattern.
The discussion drifted away from the original topic [as it's often the case in this newsgroup ;-)] From a previous post: > On 8/30/11 1:10 PM, Jonathan M Davis wrote: >> std.file.copy is synchronous. Would the suggestion then be to change >> it to be >> asynchronous or to create a second function (e.g. copyAsync) which >> does an >> asynchrous copy? > > I think std.file.copy should do whatever the heck is best to copy a > file. As such, it should be transparently asynchronous. It would be > great if such a task caught your fancy - and don't forget to test > speed under a few circumstances. > > Andrei >Implemented properly there is absolutely no >need to complicate the whole show with threading (unless you're on >windows where there's only IOCP). At any rate curl provides an async >api which one would assume is relatively sane so once again I'm not >sure how this speculation is appropriate. I guess that an "async" copy as discussed here won't bring any performance gain. But the async* methods in the curl-wrapper still have an important use case: It's the only way to treat curl http streams as a range: Curl's callback based 'push' api doesn't work well with 'pull' based ranges. This could also be done with curl's multi interface, but that has it's own issues: http://curl.haxx.se/mail/lib-2000-12/0013.html http://curl.haxx.se/mail/lib-2007-06/0239.html http://curl.haxx.se/mail/lib-2005-10/0044.html > >I'll also note that I doubt very much that this cost would be >significant in any way when compared to http overhead. > >As well as this, as an API issue I don't think a shortcut method for >avoiding the HTTP verb is a good idea. Being explicit as to what >you're doing is very much appropriate and hiding the verb because you >don't have any understanding of HTTP is not a fantastic decision. -- Johannes Pfau
