Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!

Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!
From: Stian Zeljko Vrba (vrba_at_[hidden])
Date: 2019-03-18 06:55:33

Oh, I know about possible caveats of Task.Wait. It's on its own worker thread, and that thread also arranges that only one async operation is in flight. And in case of timeout, the whole (composite) operation on that file is aborted, so if the task is still hanging somewhere and waiting for completion... it doesn't matter; the whole operation will have been marked as failed by the time it's completed and the thread will have moved on to the next file.

Task is MS's weird name for a future (TaskCompletionSource being the promise part), and the language (ab)uses Task<T> return value to transform async/await into state machines. THIS -- in combination with async/await (that also includes UI) -- is the situation when most (all?) caveats of waiting on a task arise, and THAT is an anti-pattern. This is not the case in my code. (Even that "anti-pattern" can be made safe with ConfigureAwait.)

Even the official Microsoft documentation (tutorial) teaches how to use Wait: https://docs.microsoft.com/en-us/dotnet/api/system.threading.tasks.task?view=netcore-2.2 ; indeed Wait is essential for fork-join parallelism or other asynchronous computations.

As for using synchronous API: no-go. Timeout is most likely due to network disk having disappeared, which puts the thread (on Linux, possibly OSX as well) into uninterruptible sleep, so I'd have to manage my own thread pool... and then the future/thread/blocking-queue solution I hinted at becomes even more complicated.

Because of uninterruptible sleep, not even the async Task may be cancellable, so I just let it hang and let the thread pool take care of spawning a new thread if necessary (assuming that async IO completion needs a dedicated thread on the platform.)

Thanks for the input though.

-----Original Message-----
From: Boost-users <boost-users-bounces_at_[hidden]> On Behalf Of Gavin Lambert via Boost-users
Sent: Monday, March 18, 2019 01:11
To: boost-users_at_[hidden]
Cc: Gavin Lambert <boost_at_[hidden]>
Subject: Re: [Boost-users] Networking TS + Beast, NEW Tutorials, Read this to learn std::net !!!

On 16/03/2019 03:38, Stian Zeljko Vrba wrote:
> As a followup and a concrete example, here's what C++ is competing 
> against; this piece of C# code starts an asynchronous read of a file 
> and waits for it to complete up to some timeout value; only platform 
> facilities are used here (i.e., no external libraries).
[...]
>                 var vt = sourceFile.ReadAsync(writeTask.Data);
>                 if (vt.IsCompletedSuccessfully) {
>                     bytesRead = vt.Result;
>                 }
>                 else {
>                      var t = vt.AsTask();
>                      if (!t.Wait(State.TransferTimeoutSeconds * 1000))
>                          throw new AggregateException(new 
> TimeoutException("Reader timed out."));

FWIW, using Task.Wait is in general not recommended.  It's relatively safe on a worker thread that is only doing one async thing (but not always safe if there are multiple async operations).  It's pretty much never safe to call it on the UI thread.

In fact async-and-then-wait is an anti-pattern, since the code is not actually asynchronous at all.  You should either make it actually asynchronous or use the synchronous read API instead.

(As it is, the task actually continues running even when your "timeout" 
occurs, because you're not using task cancellation correctly.) _______________________________________________
Boost-users mailing list
Boost-users_at_[hidden]
https://lists.boost.org/mailman/listinfo.cgi/boost-users