* MARK CALLAGHAN <mdcallag@stripped> [09/08/20 00:18]:
> Can someone explain the history of this code? That is, why was the
> alarm thread used for read/write timeouts rather than
> SO_SNDTIMEO/SO_RCVTIMEO?
A socket library doesn't have to rely on SO_SNDTIMEO/SO_RCVTIMEO,
it could use poll/select and non-blocking I/O instead.
However, allegedly, neither of that worked properly in early
linux kernels (2.0 series) and Windows days, as well as on some
other systems MySQL supported.
> Has anyone had success defining NO_ALARM so that SO_SNDTIMEO and
> SO_RCVTIMEO are used? I will soon try that myself. Well, I assume that
> NO_ALARM will do that but I have to look at the preprocessor output as
> the code in question is full of ifdefs.
I hear that drizzle removed the alarm thread completely.
We, at least, need to do remove its usage from the I/O layer, and
use socket options for timeouts instead.
Generally socket send/recv needs an overhaul, I know of no reason,
for example, why we constantly tweak the blocking/non blocking
socket option in net_real* functions.
We may still need the alarm thread itself, but for other reason -
SQL timeouts (AKA query timeouts, WL#1272).
I'd gladly look at any patch that removes the alarm thread from
I/O as well as at measurements that show when it becomes a
bottleneck.
--
