Am 20.03.2017 um 17:08 schrieb Carl Sturtivant:

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.
https://en.wikipedia.org/wiki/Asynchrony_(computer_programming)

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 [1] says that async runs runTask or runWorkerTask. The documentation of runTask [2] 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. :(

Maybe it would have been a better idea to create two differently named
functions to make the mechanics more explicit.

The way it works now is that there are two flavours of async: one that
works in a different thread and one that works in the calling thread.
The choice gets made based on the type of the callback - only if it can
be safely called within a different thread (function or shared <br>delegate, with parameters that can be passed between threads), it will.