Sync, Async, Blocking and Non-Blocking | Rock the JVM

[@mourikogoro9709]

6:38 "Actor ... is not something active. It's just a data structure." This enlightened me. Brilliant tutorial!

[@rockthejvm]

So glad it clicked!

[@cody8708]

Wow.. I read multiple articles without it clicking. I watched your video and felt like I understood it well before it was even over. Thanks a bunch, you're an awesome instructor

[@rockthejvm]

Thank you!

[@hrizony7847]

Thank you. But I am a little confused. 15:11 why it’s not blocking. When you call the method you still need to wait the result from another thread right? Forgive my dumbness, I really don’t understand the difference between it and Async non blocking here 4:57.

[@adityaprasad465]

Depends on what "you" means here. The println has to wait, but the thread will keep running. For example, if the next line said println("hi"), then it could execute even before the promise is fulfilled.

[@waagnermann]

in the last line you call asyncNonBlockingResult.onComplete(...) which will be executed in one of the global execution context’s threads. question: how this thread will know about the future completion (which will be completed in the actor’s dispatcher’s thread pool)? will the dispatcher’s thread somehow notify the globals’s thread that future is completed and is ready to be used in onCompleted(..) block?

[@rockthejvm]

Something like that. The execution context also has a small scheduler which is able to run callbacks and Future transformations like map/flatMap.

[@yannikschroder3381]

Awesome video! One thing that i dont understand is if u take the example of making a HTTP request or call to a database. I understand that if this call is made asynchronous, the calling thread can continue working, but the Thread waiting for the Future to complete is blocked. However, if you do this with Actors, the fact doesn't change that by the nature of the HTTP request or database it will take some time to complete the result, so it still blocks the execution somewhere, right?

[@rockthejvm]

We're concerned with whether the thread itself is waiting. If you fire the call and the thread moves to other tasks, it's not blocked.

[@francis.joseph]

this is not getting

[@hrizony7847]

⁠​⁠​⁠​⁠@@rockthejvmin line28 you said the blocking aspect of the program is that there is another thread that is blocking. IIUC, that doesn’t block the main calling thread. So as far as call thread itself concerned, it is nonblocking right? In the last example, if I also let thread sleep, for example in line33. that means that thread that will work on the action in the future will be blocked. In that sense there is also a blocking aspect in this solution? So I’m confused and it looks like whether to have thread.sleep is what determines one blocking or non-blocking?

[@mingHiewNN]

Thank you for the fantastic work, Daniel! Btw, I'm just wondering if you have any plan to do a course on the akka typed actor and make it available on Udemy or RockTheJVM, as I'm really looking forward to it

[@rockthejvm]

On the roadmap - it will take some time as the material is massive, so thanks for the patience!

[@Krazness]

Thanks for these great videos. Do you have any resources on writing and debugging Futures with the ScalaTest framework? I've been trying to use IntelliJ's debugger and evaluate tool to follow the code paths. But I'm not getting through

[@jurevreca9229]

Thank you for this great tutorial. Could you please explain the syntax at 7.45. Specifically the syntax that confuses is me is the "someMessage=> {the function block}". As far as I understand the "=>" operator is used to define types. I.e. you can define the type definition of a function. So what does this syntax mean?

[@rockthejvm]

Check the Scala at Light Speed video that talks about functions, we have everything there.

[@nao_concordo]

Thank you, pretty nice like always. Do you have any plans to do a course about ZIO ?

[@rockthejvm]

Perhaps - shout in the comments if anyone else needs ZIO!

[@shef9192]

Zio +

[@nullptr7]

Yes zio would be great 🔥

[@ketanpurohit9086]

Very good lesson - interested in finding out why the application does not terminate. Is there some event-loop running?.. if so is there a 'stop' method. Edit: The actor systems have to be terminated. rootActor.terminate() and promiseResolver.terminte()

[@rockthejvm]

There's the execution context running, which needs stopping.

[@waagnermann]

Do you think you made non-blocking operation just because you have removed from the third case "Thread.sleep(10000)" line which occured in first two cases? If I put this line to the code-block that will be executed by ActorSystem then there`ll be also a blocking. The only difference is that this blocking will block the dispatcher`s thread, but since dispatcher, global execution context and a main thread are placed on the same machine - then what`s the profit of the model (with promises) that you`ve shown?))))))))

[@rockthejvm]

The sleeps are just for illustration, I think you got the idea.

[@georgezorikov3075]

Good video, thank you! One question, if you allow me. Let's say we have 1 processor, 1 core machine. Will Futures and Asyncs run concurrently, I mean, 1 thread jumps back and forth from one task to another, imitating concurrency, or will it be sequential operations with a fully determined order?

[@rockthejvm]

Nope, still concurrent. The OS can schedule and interrupt threads on the same physical core at (almost) any time, so the same conditions for multithreading still apply.

[@mr_kurro]

I am a big fan of your courses on RTJVM. I have a question: “Using actor is asynchronous and non-blocking”, in short, the idea is delegating “blocking thing” to actor’s dispatcher and benefit from its better scheduling, isn’t it?

[@rockthejvm]

You're not delegating anything to an actor - you're just sending it a message. The internal logic of the actor will run at some point, on some thread. The end goal is not necessarily better thread scheduling (although that is also true) but better isolation of logic in your application, without needing to care about threads at all.

[@victorpre]

another great video

[@sathisg]

Will the main thread not block if message is being sent to Remote actors mail box?

[@rockthejvm]

Never - message sending is fully non-blocking

[@unimatrixz3ro226]

It's an amazing video, thanks :)

[@Gohel95]

Thanks💕💕💕

[@coffeezealot8535]

haha nice parrot