Am Dienstag, 27. Oktober 2015 11:24:21 UTC+1 schrieb lutzh:
Hi Haddock,
Fibers as such do not prevent you from blocking. Pretty much like in Akka,
if you use blocking I/O you block the underlying thread, which is then of
course not available for other fibers or actors. So async I/O it is.
The fibers approach to it is to provide a FiberAsync wrapper, see the
section "Transforming Asynchronous Operations into Fiber-Blocking
Operations, and Fiber-Blocking IO" in the blog you refer to.
This is also a nice example for fibers value proposition - it provides
this wrapper to allow you to continue to program in a sequential /
imperative style, without using callbacks.
Hi Haddock,
Fibers as such do not prevent you from blocking. Pretty much like in Akka,
if you use blocking I/O you block the underlying thread, which is then of
course not available for other fibers or actors. So async I/O it is.
The fibers approach to it is to provide a FiberAsync wrapper, see the
section "Transforming Asynchronous Operations into Fiber-Blocking
Operations, and Fiber-Blocking IO" in the blog you refer to.
This is also a nice example for fibers value proposition - it provides
this wrapper to allow you to continue to program in a sequential /
imperative style, without using callbacks.
This is true for fibers in general, the whole idea is that you introduce a
sub-thread level unit of concurrency, but don't change the programming
model - much like goroutines in go.
"much like goroutines in go". Yep, this is the point ;-).sub-thread level unit of concurrency, but don't change the programming
model - much like goroutines in go.
When using Akka, you opted for a different model altogether already - async
messaging. Therefore I don't think it would be a good fit, it would not be
idiomatic Akka, in fact it would be a programming model contradicting
Akka's ideas.
I see the point. Agree.idiomatic Akka, in fact it would be a programming model contradicting
Akka's ideas.
To me, doing async I/O either with Future-based APIs and pipeTo, or using
Reactive Streams, seems a much better fit for Akka.
What's in the case of Akka the way to prevent threads (that is actors) fromReactive Streams, seems a much better fit for Akka.
blocking when doing blocking IO (querying databases, doing REST calls,
reading from files, etc.)? Go through NIO or is there some stuff provided
for this?
Thanks for any answers.
Regards, Haddock.
--
Read the docs: http://akka.io/docs/
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
Check the FAQ: http://doc.akka.io/docs/akka/current/additional/faq.html
Search the archives: https://groups.google.com/group/akka-user
You received this message because you are subscribed to the Google Groups "Akka User List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to akka-user+unsubscribe@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
