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
