All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: David Herrmann <dh.herrmann@gmail.com>
Cc: BlueZ development <linux-bluetooth@vger.kernel.org>,
	Johan Hedberg <johan.hedberg@gmail.com>,
	Michael Biebl <mbiebl@gmail.com>
Subject: Re: [PATCH] core: fix unbound watchdog-notify for timeouts <2s
Date: Sun, 14 Sep 2014 10:54:24 -0700	[thread overview]
Message-ID: <CAA4C4BB-35EF-41A3-8403-D2A7DD8FE7B2@holtmann.org> (raw)
In-Reply-To: <CANq1E4QdKVCVVk6o=dP9vqsVP7fAe6ROhoMcw_y0Pp+oi5O0zA@mail.gmail.com>

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


      reply	other threads:[~2014-09-14 17:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-13 13:21 [PATCH] core: fix unbound watchdog-notify for timeouts <2s David Herrmann
2014-09-13 16:54 ` Marcel Holtmann
2014-09-13 19:11   ` David Herrmann
2014-09-14 17:41     ` David Herrmann
2014-09-14 17:54       ` Marcel Holtmann [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA4C4BB-35EF-41A3-8403-D2A7DD8FE7B2@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=dh.herrmann@gmail.com \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=mbiebl@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.