On Mon, 20 Mar 2017 07:46:07 GMT, Jacob Carlborg wrote:
The whole vibe framework is built around asynchrony IO and fibers.
I was misled long ago by the D Web Development book into thinking async was provided as an escape from the framework, i.e. for asynchronous execution of a function in a new thread because that function cannot be conveniently rewritten with occasional calls to yield. I knew I would find that a convenience so I remembered it.
I checked my sanity just now and found in chapter 7 it overtly says this, Title: "Using a Thread" , p.130-3 says "The computation is done in a separate thread" and "The async function is used to start the computation", and these several pages are entirely an extended example of "using a thread".
The word "asynchronous" applies to concurrency and parallelism as well as asynchronous I/O.
So when I looked at the async documentation and saw the first paragraph is "Starts an asynchronous computation and returns a future for the result value." this was completely consistent with conclusions I had formed way back when I read the book.
Of course it didn't say "in another thread" so I really should have understood by that omission that this was default asynchrony for vibe.d, NOT as the book said. But I unsuspiciously went with the book until proved otherwise in practice. Hence my request for confirmation.
The documentation  says that
runWorkerTask. The documentation of
taskwill be called synchronously from within the vibeRunTask call. It will continue to run until vibeYield() or any of the I/O or wait functions is called."
OK, should have pursued that reference, as this is overtly asynchronous I/O. But I did not believe the book would contain an entire section on an overt falsehood. :(