Re: Good guy timers

On 3/27/2014 5:37 AM, David Barbour wrote:
>
> I take it you're most familiar with 'dead' resources - I.e. passive 
> between external requests or commands - not live ones (like live 
> video, or live robot control, or live pubsub) that continue to act 
> until asked to stop. Every response you make below seems to assume 
> passive resources with active request streams, but there are entire 
> problem domains with low rate control streams on active resources.
>
> In my experience, the main reason for timeouts is not that a local 
> thread gets 'stuck', but rather that some upstream thread with a 
> socket used by a local thread gets stuck... or that a human supervisor 
> isn't paying attention.
>
> I think good guy timers are usually a bad idea for live resources.
>

Interesting.  I'd like to understand why.  I'm not sure I understand the 
breadth of all the examples you refer to, but your mention of a human 
supervisor who isn't paying attention seems to me a particularly good 
case for good guy timers.

 From my perspective the reason for timing something out is that some 
resource is being consumed that needs to be recovered and used for 
something else.  If such a resource won't be required elsewhere, then 
why not wait forever?  Why have a timeout at all?

When you give the example of a human supervisor who isn't paying 
attention, is the idea of the timeout that you want to provide a 
reminder?   That is, there isn't a scarce resource whose recovery will 
abort a transaction.  In fact if the reminder is successful then the 
interaction can continue.  In such a case it seems to me that a reminder 
triggered by a time is essentially out of band.  It isn't terminating a 
transaction, but rather is a prompt in an effort to speed it along.  In 
this sense it's more like a retry of a packet (which itself has a time 
value, but not what I was considering a "timeOUT", but rather a prompt 
or retry) for which an ack hasn't yet been received - rather than a 
timeOUT of an attempt to give up an attempted send because repeated 
packets haven't been acked.  Am I understanding your example?

Perhaps it would help me to understand your perspective if you could 
give an example of a "live resource" such as those you refer to (live 
video, live robot control, or live 'pubsub') and the describe how a non 
"good guy" timeout (in the sense of a give up and not in the sense of a 
prompt or retry) would be helpful for some sorts of transactions where a 
"good guy" timeout would be counter productive.

Thanks for taking the time to clarify.

--Jed

<the rest is historical>

> On Mar 27, 2014 2:26 AM, "Jed Donnelley" <capability-iCFHVraI1K1Wk0Htik3J/[email protected] 
> <mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]>> wrote:
>
>     On 3/26/2014 10:46 AM, David Barbour wrote:
>>
>>     On Wed, Mar 26, 2014 at 12:02 AM, Jed Donnelley
>>     <capability-iCFHVraI1K1Wk0Htik3J/[email protected] <mailto:capability-iCFHVraI1K1Wk0Htik3J/[email protected]>> wrote:
>>
>>
>>         The only reason timers (at least at the top level - there are
>>         some other
>>         issues at the bottom) are needed is to deal with resource issues.
>>
>>
>>     There are also "dead man's switch" issues (e.g. if controlling a
>>     robot through a web page).
>
>     I'm not sure I understand the "dead man's switch" issue that you
>     mention above.
>     However, regarding:
>
>>     And some kinds of resources might be problematic if kept around
>>     without a consumer (e.g. server-side video acquisition and
>>     buffering is expensive, and buffers quickly become more so if not
>>     consumed). Depends on the problem domain.
>
>     It seems to me that such buffering would be suitable for a "good
>     guy" timer
>     mechanism as such buffers would be available at need (unless requested
>     before a very short timeout), but held buffers would not be
>     recycled before
>     they were needed.
>
>>
>>         We did have a "timeout" - that is a time after which we would
>>         consider
>>         recycling such threads before their processing was complete.
>>          However,
>>         we only did so if they were needed for incoming requests.
>>          The basic
>>         idea was that we had a trigger value (minimum number of available
>>         threads) below which we would look for threads to recycle.
>>          We wouldn't
>>         consider any threads that hadn't yet reached their "timeout"
>>         value (in
>>         that case if we ran out of threads we would block incoming
>>         requests) and
>>         we would recycle others on an oldest first basis.
>>
>>
>>     This is a nice approach, assuming relatively passive resources.
>
>     I'm not sure what you mean by "passive" in the above context.  The
>     threads
>     that we recycled tended to be rather active unless stuck,
>     constantly being
>     used for processing incoming requests.
>
>>     I've been contemplating a similar technique, albeit at the
>>     session state layer (i.e. allowing old sessions to be resumed,
>>     but recycling those more than a month old or so).
>
>     The key for us was to:
>
>     1.  Not simply throw away state and recycle resources based on a
>     time expiring, but
>
>     2.  Only recycle such resources if a time had expired AND the
>     resource was needed
>     (e.g. we were experiencing something like a DOS attack or some
>     other high load
>     with low response clearing).
>
>     With such an approach we could also set the timeout value
>     relatively tight
>     because it would almost never trigger abortion of a request whose
>     processing
>     was delayed - since they were being "good guys" and only
>     triggering at need.
>
>>
>>         friam/cap-talk
>>
>>
>>     I hadn't heard of the friam google group. I guess I'll need to
>>     check it out.
>
>     --Jed
>

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