Posted Mon, 20 Mar 2017 16:08:05 GMT in reply to Jacob Carlborg
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
runTask  says:
task will 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. :(