Everything's talking about the same principle -- the question is focus:

On Wed, Feb 22, 2017 at 4:31 AM, <[email protected]> wrote:

> I read in many articles/SO posts, that the term *blocking* generally
> means a caller (and therefore the thread it executes in) will *wait* until
> some data is returned (or times out maybe).
>
This is talking about what blocking *is*.

> In akka.io docs however it talks about *blocking* only in terms of one
> thread possibly causing other threads to have to wait ie. it may block the
> progress of other threads eg. several threads all trying to acquire same
> resource lock.
>
This is talking about why blocking is a *problem*.

(Really, even deadlocks are something of a distraction: if you are blocking
too casually, you can run out of available threads.  That's the thing:
blocking is fine for the thread that is blocking, but it's tying up a
limited resource.)

By and large, a properly-constructed Akka program doesn't need to worry
about threads at all -- the underlying engine takes care of all of the
threading.  But this depends on the threads being available, and that, in
turn, means not chewing them up by blocking inside of Actors.  Which is why
the rule in Akka is to never block inside an Actor until you *absolutely*
must -- and if you must block, generally use a dedicated Dispatcher for the
purpose so that those Actors don't use the same thread pool as everybody
else...

-- 
>>>>>>>>>>      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
--- 
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.

Reply via email to