> Well, I think touching requests_this_child is not really what we'd want an > API for. Since changing that value isn't really what we are after. We are > looking for an API to allow clean child termination, so I would suggest > more precisely to implement something like ap_mpm_child_terminate() API > that could certainly be implemented by setting requests_this_child to zero. > But the intent of the api is/should be child termination, allowing various > MPMs to do it differently (if at all (thinking win32 mpm)).
right, that's pretty much what I meant - offer an appropriate ap_ API (like ap_mpm_child_terminate that you suggested) but have it toggle the appropriate switches to allow for an elegant process cleanup. as for names, I'd suggest staying away from "child"-based names, since it probably doesn't make sense for mpms outside of prefork. maybe ap_process_terminate or ap_mpm_process_terminate (for process versus thread, instead of child versus parent). whatever we choose it should be intuitive in name for each mpm. >> if the requests_this_child approach isn't sufficient, forget this email ) > > > It's not quite sufficitent, as in worker, for instance, you'd need to set > requests_this_child < 0 and also make MaxRequestPerChild > 0. right, but the idea is the same - allow termination via standard apache processes that are (currently) private but already in place. > > Attached is a possible patch for worker and prefork, the other mpms are > left > to do. hmm, well that's certainly a nice tidy solution :) but I thought there were problems with just sending signals? (though I admit that I got a bit lost in all the to-and-fro between you and stas here). --Geoff --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
