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