RejectedSoftware Forums

Sign up

different async problem

In code that doesn't call getResult, a call to async to run a very long task is not returning, but rather is running the call as if it is a regular (synchronous) function call, and only returns a future when the call is done. This happens with the old vibe core and with the new one (1.0.0.beta-4). I'll be sticking with the new one henceforth.

I've been working to get a small piece of code to replicate this effect without success so far. Wondering if this suggests anything?

Re: different async problem

On Sat, 18 Mar 2017 09:38:39 GMT, Carl Sturtivant wrote:

In code that doesn't call getResult, a call to async to run a very long task is not returning, but rather is running the call as if it is a regular (synchronous) function call, and only returns a future when the call is done.

I've made the simple and intuitive discovery that a call of sleep(100.msecs) at the start of the body of the function asynchronously called obviates the problem.

Re: different async problem

On Sat, 18 Mar 2017 22:50:11 GMT, Carl Sturtivant wrote:

On Sat, 18 Mar 2017 09:38:39 GMT, Carl Sturtivant wrote:

In code that doesn't call getResult, a call to async to run a very long task is not returning, but rather is running the call as if it is a regular (synchronous) function call, and only returns a future when the call is done.

I've made the simple and intuitive discovery that a call of sleep(100.msecs) at the start of the body of the function asynchronously called obviates the problem.

Unfortunately, that means I have likely misunderstood async --- the D Web Development book I read some time back when it came out, said it runs its argument(s) in a separate thread, but this looks to be false, i.e. it's cooperative multitasking. Please confirm.

Re: different async problem

On Sun, 19 Mar 2017 23:46:12 GMT, Carl Sturtivant wrote:

Unfortunately, that means I have likely misunderstood async --- the D Web Development book I read some time back when it came out, said it runs its argument(s) in a separate thread, but this looks to be false, i.e. it's cooperative multitasking. Please confirm.

The whole vibe framework is built around asynchrony IO and fibers. 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."

[1] http://vibed.org/api/vibe.core.concurrency/async
[2] http://vibed.org/api/vibe.core.core/runTask

/Jacob Carlborg

Re: different async problem

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. :(

Re: different async problem

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.

Re: different async problem

On Thu, 23 Mar 2017 20:37:01 +0100, Sönke Ludwig wrote:

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.

So there is one that runs in a thread! OK, now I look at runWorkerTask as opposed to runTask in the API, it becomes clear. It says "thread". Well, at least D Web Development wasn't out-and-out false about this.

I agree with you that this is better dealt with by two differently named functions, because right now, silently, one may be calling the Fiber version thinking one has an independent thread. The results are very different!

I suppose there's code that relies upon async in its present bifurcating form. Could you add a new function that forces weak isolation where needed e.g. via copying, and always uses a thread? Is this a good idea?