Unfortunately that's like many of our explanations, too open-ended to
be very helpful when someone sits down to write some code.
On Wed, Oct 10, 2018 at 2:26 PM Alan Carroll
<solidwallofc...@oath.com.invalid> wrote:
>
> To accomodate different behavior requirements on the continuations
> scheduled on a thread in that pool. E.g. non-blocking vs. blocking for one.
>
> On Wed, Oct 10, 2018 at 2:25 PM Walt Karas <wka...@oath.com.invalid> wrote:
>
> > Why do we need thread pools?
> > On Wed, Oct 10, 2018 at 2:17 PM Alan Carroll
> > <solidwallofc...@oath.com.invalid> wrote:
> > >
> > > Yes, that's not well developed. However, it is the reason TS mutexes are
> > > shareable. If there is a resource shared between continuations the TS
> > > approach is to have those continuations share the same mutex leading to
> > > natural rescheduling for lock contention. In addition, that TS mutexes
> > are
> > > recusive makes it so that if you can arrange for all of the continuations
> > > sharing a resource to be on the same ET_NET thread then locking is
> > > effectively cost free, yet remains robust in the cases where there is
> > > actual lock contention.
> > >
> > > Because of the proxy (pass-through) nature of I/O in TS, it's quite
> > > difficult to keep shared resources on the same thread if outbound
> > sessions
> > > are shared across threads. It is also problematic in the case of
> > scheduling
> > > to and from different thread pools (although Fei's work should address
> > to a
> > > large extent).
> >
>
>
> --
> *Beware the fisherman who's casting out his line in to a dried up riverbed.*
> *Oh don't try to tell him 'cause he won't believe. Throw some bread to the
> ducks instead.*
> *It's easier that way. *- Genesis : Duke : VI 25-28
