Re: Good guy timers

On Sun, Mar 30, 2014 at 2:01 AM, Jed Donnelley <capability-iCFHVraI1K1Wk0Htik3J/[email protected]>wrote:

>
> your mention of a human supervisor who isn't paying attention seems to me
> a particularly good case for good guy timers.
>

Your 'good guy' timers are essentially just a way to avoid actually timing
out unless there is a competitor for the resources. However, timers for
human supervisors are more often for things like "okay, we're about to
crash. please select one of these actions or perform another within 3
seconds, or I'll need to guess which action is best." Timeouts are often
relevant in domains where timing of actions and commitment to actions are
relevant.

For something like live videos, timers are necessary not due to a human
supervisor but due to buffering issues.  There is a limit to how much one
can buffer live video while waiting for the remote client to fetch them.

Now, there are ways around this for video (such as using a ring-buffer and
accepting lossy video in case of timeout). But it can also be expensive to
keep producing video, in terms of battery life and so on, e.g. if the video
is coming from a remote robot platform. And it might not be so expensive to
simply restart the video. So one needs to prioritize. Your 'good guy
timers' would favor to keep the video running and buffering in case someone
is debugging the code or similar, unless someone else needs the video
stream.


>
> From my perspective the reason for timing something out is that some
> resource is being consumed
>

I think that's a very limited perspective. Timeouts can be used for a fair
number of reasons, including semi-autonomous systems and robust
health-maintenance (e.g. watchdog timers on heartbeats), and even
partitioning tolerance. Recovering exclusive resources is just one use of
timers, is it not?

_______________________________________________
cap-talk mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/cap-talk