>> 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 _______________________________________________ 389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@xxxxxxxxxxxxxxxxxxxxxxx
