Hi David, >>> I get the feeling that if > 2s, then we should use g_timeout_add_seconds to get the advantage of being woken up with all other timeouts in our daemon. And when it is <= 2s, then we better use a high precision g_timeout_add. >> >> This sounds actually good. I will do that in v2. > > Ok, glib only supports millisecond precision, so whatever we do, there > will be a WATCHDOG_USEC range that we cannot react to properly. Ok, to > be honest, if WATCHDOG_USEC is below 1ms, we're screwed anyway, so > maybe we should just keep our current behavior.. I mean there is > nothing sane to do for use if users specify such low watchdog ranges. > At some point, we have to resort to either run watchdogs without a > timeout or bail out and tells users to stop using such low values. > Whether this is at 1s or at 1ms doesn't matter much, does it? I am fine with just bailing out and terminating the daemon with an error exit code in case the watchdog timeout is < 2 seconds. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
