cancelling requests due to max_request_time

[Alan DeKok]

Frank Cusack wrote:

>> Is that right?  There are bugs there (besides pthread_cancel())?

  Perhaps.

>>  I see
>> that if delete_block_requests is no, pthread_cancel() doesn't get
>> called and instead STOP_NOW is set, so that looks good since usu. a
>> request would be blocked on I/O, not compute, so waiting for a module
>> to complete some I/O shouldn't be an issue.

  Except for issues like DNS, or SQL servers being down, or LDAP being
non-responsive for minutes.  But yes, it will mostly work.

>> I would suggest simply removing the delete_blocked_requests option
>> (always use "no").  The STOP_NOW flag looks good enuf.

  OK.

> Thought more about this.  Maybe a global cancel handler which calls
> into a new .cancel method of each module.  If the module doesn't have
> this function it won't be cancelable.  Hey I like that a lot.

  That's easy enough to do.  But if a module is cancellable, odds are it
won't be blocking on anything...

> Just need to ensure delete_blocked_requests isn't actually buggy.

  Now that I think about it, the request has to be deleted from the
"live" list, and placed onto a "dead" list.  That's so its memory isn't
leaked.

  I spent some time trying to come up with a good & easy solution, but
it never went anywhere.  The "packet list" stuff in CVS head is a start,
but not completely fleshed out.

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog