What is the difference in calling Future and Future.microtask in Flutter? - flutter

From the documentation for the Future.microtask constructor, it says:
* Creates a future containing the result of calling [computation]
* asynchronously with [scheduleMicrotask].
and the documentation for the regular Future constructor states:
* Creates a future containing the result of calling [computation]
* asynchronously with [Timer.run].
I am wondering, what kind of implications do they have on coding, and when should we use one or another?

All microtasks are executed before any other Futures/Timers.
This means that you will want to schedule a microtask when you want to complete a small computation asynchronously as soon as possible.
void main() {
Future(() => print('future 1'));
Future(() => print('future 2'));
// Microtasks will be executed before futures.
Future.microtask(() => print('microtask 1'));
Future.microtask(() => print('microtask 2'));
}
You can run this example on DartPad.
The event loop will simply pick up all microtasks in a FIFO fashion before other futures. A microtask queue is created when you schedule microtasks and that queue is executed before other futures (event queue).
There is an outdated archived article for The Event Loop and Dart, which covers the event queue and microtask queue here.
You can also learn more about microtasks with this helpful resource.

Here is a simple example of how code would run in sequence in terms of how Futures are executed. In the example below, the resulting print statements wouldn't be in alphabetical order.
void main() async{
print("A");
await Future((){
print("B");
Future(()=>print("C"));
Future.microtask(()=>print("D"));
Future(()=>print("E"));
print("F");
});
print("G");
}
The resulting print statements would end up in the order shown below. Notice how B, F, and G gets printed first, then C, then E. This is because B,F, and G are synchronous. D then gets called before C and E because of it being a microtask.

Related

Dart - Nested then never completes

I would like to have nested then callbacks as below:
somemethod1 and somemethod2 inside both functions return future.
Future<T> **somefunctionA**() => ...somemethod1().then((value) => return T);
Future<T> **somefunctionB**() => ...somemethod2.then((value) async {
await **somefunctionA**();
/// then post processing...
}).then((value) => do something);
I have implemented this, but the nested then callback inside somefunctionA never completes.
Instead, the outer then callback to somefunctionB gets called once the future inside somefunctionA completes.
How do I make this work in such a way that the inner then callbacks must be completed before the outer then executes?
Any help would be appreciated.

While the inner method async does the outer method has to be async?

I have an async method. Can I call it from an non-async method? Like the following
My method
void method() async{
await 'something'
}
Case 1
onPressed:() {
method();
}
Case 2
onPressed:() async{
await method();
}
Which of the above is correct? It seems to me two of them is OK. However, the second one I think works much more slower, am I wrong?
In general, the caller of an async function must also be asynchronous if it wants to wait for the call to complete. This makes asynchronous-ness contagious.
In your case, your async function is a "fire-and-forget" function; callers cannot wait for it to complete, so it doesn't matter. Your second case (with await method()) is wrong because you should use await only on Future/FutureOr, but method returns void, so there nothing to wait for. (The Dart analyzer would warn you about this if you have the await_only_futures lint enabled.)
You also could simplify your code further by using a tear-off instead of creating an unnecessary closure:
onPressed: method

Scala futures and JMM

I have a question about JMM and Scala futures.
In the following code, I have non-immutable Data class. I create an instance of it inside one thread(inside Future apply body), and then subscribe on completion event.
import scala.concurrent.ExecutionContext.Implicits.global
import scala.concurrent.Future
object Hello extends App {
Future {
new Data(1, "2")
}.foreach { d =>
println(d)
}
Thread.sleep(100000)
}
class Data(var someInt: Int, var someString: String)
Can we guarantee that:
foreach body called from the same thread, where a Data instance was created?
If not, can we guarantee that actions inside the Future.apply happens-before(in terms of JMM) actions inside foreach body?
Completion happens-before callback execution.
Disclaimer: I am the main contributor.
I had a sort-of similar question, and what I found is -
1) in the doc Intellij so conveniently pulled up for me it says
Asynchronously processes the value in the future once the value becomes available...
2) on https://docs.scala-lang.org/overviews/core/futures.html it says
The result becomes available once the future completes.
Basically, it does not anywhere I can find say explicitly that there is a memory barrier. I suspect, however, that it is a safe assumption that there is. Otherwise the language would simply not work.
No.
You can get a good idea of this by looking through the source code for Promise/DefaultPromise/Future, which schedules the callback for foreach on the execution context/adds it to the listeners without any special logic requiring it to run on the original thread...
But you can also verify it experimentally, by trying to set up an execution context and threads such that something else will already be queued for execution when the Future in which Data was created completes.
implicit val context = ExecutionContext.fromExecutor(Executors.newFixedThreadPool(2))
Future {
new Data(1, "2")
println("Data created on: " + Thread.currentThread().getName)
Thread.sleep(100)
}.foreach { _ =>
println("Data completed on: " + Thread.currentThread().getName)
}
Future { // occupies second thread
Thread.sleep(1000)
}
Future { // queue for execution while first future is still executing
Thread.sleep(2000)
}
My output:
Data created on: pool-$n-thread-1
Data completed on: pool-$n-thread-2
2.
Less confident here than I'd like to be, but I'll give it a shot:
Yes.
DefaultPromise, the construct underlying Future, is wrapping an atomic reference, which behaves like a volatile variable. Since the write-to for updating the result must happen prior to the read-from which passes the result to the listener so it can run the callback, JMM volatile variable rules turn this into a happens-before relationship.
I don't think there are any guarantees that foreach is called from the same thread
foreach will not be called until the future completes succesfully. onComplete is a more idiomatic way of providing a callback to process the result of a Future.

What is the difference of Future/Await and Async/Await

In Scala and other programming languages one can use Futures and Await.
(In real code one would use e.g. zip+map instead of Await)
def b1() = Future { 1 }
def b2() = Future { 2 }
def a() = Future {
Await.result(b1(),Duration.inf) + Await.result(b2(),Duration.inf)
}
What is the difference to Async/Await in Javascript/Scala?
async function b1() { return 1 }
async function b2() { return 3 }
async function a() {
return await b1() + await b2()
}
The "Await.result" function in Scala is "blocking", which means that the calling thread will be paused until the awaited Future is completed, at which point it will resume with the returned value.
Pausing a thread can be expensive in a system under high load, as the thread context has to be saved in memory, and it can cause cache misses etc.. Blocking threads is considered poor practice in concurrent programming for that reason.
The async / await syntax in Javascript is non-blocking. When an async function invokes "await", it is converted into a Future, and placed into the execution queue. When the awaited future is complete, the calling function is marked as ready for execution and it will be resumed at some later point. The important difference is that no Threads need to be paused in this model.
There are a number of libraries which implement the async / await syntax in Scala, including https://github.com/scala/scala-async
Further reading
The Futures and Promises book by PRASAD, PATIL, AND MILLER has a good introduction to blocking and non-blocking ops.
Await is blocking while async is non blocking. Await waits in the current thread to finish the task while async won't block the current thread and runs in background.
I don't have idea about JavaScript. In Scala Await from scala.concurrent package is used for blocking main thread. There's another library called scala-async what is used for using await inside async block.
If you are using scala-async, then you need to call await inside async

Does MongoCollection.forEach need to be thread safe?

When using the MongoDB Async Java Driver:
Does the following callback need to use a AtomicInteger counter or would a normal int do the job?
Block<Document> theBlock = new Block<Document>() {
AtomicInteger counter = new AtomicInteger();
#Override
public void apply(final Document document) {
counter.incrementAndGet();
}
};
SingleResultCallback<Void> callbackWhenFinished = ...
collection.find().forEach(theBlock, callbackWhenFinished);
The only real difference between the MongoDB Java API and its async counterpart is that the methods of the latter are non-blocking and take callbacks as arguments. This means that what you receive in your callback is equivalent to what the method returns in the non-async API.
Here, you use the find method. It returns a "normal" iterable, so calling forEach on it will not result in multiple threads.
In other words, you don't need an AtomicInteger: your apply method is called sequentially, by the same thread.
If you still have doubts or need a "proof", you can do one of the following:
add a System.out.println(Thread.currentThread().getName()); inside your block. You will see it is always performed by the same thread;
add a breakpoint inside your block, configured to stop only the thread. Once again, the breakpoint will block the whole code.