cancelling requests due to max_request_time

Alan DeKok aland at deployingradius.com
Mon Jan 15 21:20:07 CET 2007


Frank Cusack wrote:
> request_list.c around line 574, calling pthread_cancel() on the thread
> handling a timed out request is a bad idea.  It can leave resources
> hanging, like a locked mutex for ownership of an ldap file descriptor.

  Yes.  The proper thing to do is....

> In order for pthread_cancel() to be a good idea, most modules would
> need to take care to disable cancellation while they hold resources
> open, and/or set cancellation handlers to clean them up.  That's a
> lot of work and there's a lot of room for bugs there.
> 
> But I can't think of a better approach.  You don't want to let threads
> just run to completion and waste resources.

  That's what the STOP_NOW flag is for in struct REQUEST.  It should
really be a 32-bit int of it's own, to prevent threading issues.  The
code in src/main/modcall.c (or src/main/module.c) stops processing the
request through the module list once that flag is set.

  It doesn't bring a dead thread back to life, but it stops the request
once it comes back.

  Maybe an alternative is to do pthread_kill(), which a catchable
signal.  That may interrupt blocked system calls, but there's really no
guarantee that the offending library won't simple retry.

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



More information about the Freeradius-Devel mailing list