Leandro Santi wrote:
> > I searched a little and it seems that SO_RCVTIMEO and SO_SNDTIMEO are
> > supported since Linux 2.3.41. I think we can do something like that:
> >
> > #ifdef SO_RCVTIMEO
> > setsockopt (...)
> > #endif
>
> IMHO this will work with systems that don't #define these sockopts. But
> Linux 2.2-based systems do actually #define these numbers, and don't
> implement them:
[...]
> and from my understanting of the code, the setsockopt() will probably
> return with errno=ENOPROTOOPT.
I think it's not a problem. The vio_timeout() function doesn't report
failure on errors, therefore people running obsolete systems will have
no effect when they use mysql_options() but at least nothing is broken.
BTW in the current version of libmysqlclient this is the behaviour for
all non-windows systems.
> > http://bugs.mysql.com/bug.php?id=4143
>
> Perhaps this (slower) operation mode could be enabled on demand?
Perhaps, if someone provides a patch... I don't know if this will be
accepted by the MySQL developpers.
> ps: Just for completeness. I'm currently doing timeout enforcement on
> Postfix's dict_mysql driver by carefully closing the database descriptor
> in signal (SIGALRM) handler context, and disabling automatic client
> reconnects. This hack works pretty well for me ...
In my case, I've got problems running FreeRADIUS with a MySQL backend.
I don't want to hack FreeRADIUS because I think the bug comes from
libmysqlclient: it's annoying to call a function (inside an external
library) which doesn't return in a deterministic time and eventually
hangs execution of the program.
--
Nicolas Baradakis
