Re: Good guy timers

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.
On Mar 27, 2014 2:26 AM, "Jed Donnelley" <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]>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
>
>

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