> I think turbo mode was to try and shortcut returning to the
conntable and then having the blocking on the connections poll because the locking
strategies before weren't as good. I think there is still some value in turbo
"for now" but if we can bring in libevent, then it diminishes because we become
event driven rather than poll driven.
"turbo mode" means "keep reading from this socket as quickly as possible
until you get EAGAIN/EWOULDBLOCK" i.e. keep reading from the socket as fast as
possible as long as there is data immediately available.
Yep that's how I understood it - it's trying to prevent a longer delay until
it's poll()-ed again.
This is very useful for replication consumers, especially during
online init, when the supplier is feeding you data as fast as possible. Otherwise, its
usefulness is limited to applications where you have a single client hammering you with
requests, of which test/stress clients form a significant percentage.
Don't you know though, microoptimising for benchmarks is the new and hip trend.
Joking aside, there probably are situations for now where it's still useful, but ifwe
can bring in libevent and be event driven rather than using poll() we shouldn't have
to worry to much.
Another option is when we hit EAGAIN/EWOULDBLOCK we move the task back to the slapi work q
rather than re-waiting on it in the poll phase.
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs