On Sat, 03 Dec 2011 21:17:25 +0200, Jonas Drewsen <jdrew...@nospam.com>
wrote:
Den 03-12-2011 13:10, Vladimir Panteleev skrev:
On Sat, 03 Dec 2011 13:53:16 +0200, Jonas Drewsen <jdrew...@nospam.com>
wrote:
As mentioned the async version performs the request in another thread
leaving the main thread available for you to do something else. I'll
clarify in the docs that it is when you actually call empty/front on
the returned range you will get data from the other thread and may be
blocking.
I can't think of a realistic use case for the current asynchronous API.
Basically, all you can do is start a request in the background, but
you're neither notified of the request nor can you poll it to check its
status? So the only thing you CAN do is ask for a request that you will
need in the future, and when that future moment comes, block if
necessary to get the result?
The standard example is downloading some content and saving it at the
same time.
While your main thread saves a chunk to disk (or uploads to another
server) the async thread is busy buffering incoming chunks of data. This
means that you effectively only wait for the slowest of the two IO
operations. If you did it synchronously would worst case have to wait
for all everything to be downloaded and the wait for everything to be
saved or uploaded.
foreach(chunk; byChunkAsync("www.abc.com/hugefile.bin"))
{
// While writing to file in this thrad
// new chunks are downloaded
// in the background thread
file.write(chunk);
}
I hope this makes sense.
Well, this makes sense from a theoretical / high-level perspective, but OS
write buffers greatly reduce the practicality of this. In common use cases
the speed difference between disk and wire will differ by orders of
magnitude as well.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
