URL: https://github.com/SSSD/sssd/pull/511 Title: #511: Do not shutdown KCM/Secrets responders when activities are happening ...
fidencio commented: """ @simo5, please, bear with me here. I'm a little bit confused about tevent_ops/tevent_signal/tevent_queue. Taking a look at tevent_context, there's no API to easily check whether there are pending operations or not. However, I can see a non-public API that could be used for that: `tevent_common_check_signal` (or at least I think so). Wouldn't be the case to have `tevent_common_check_signal` exposed on samba side and just add the following patch to the responder's common code? ``` --- a/src/responder/common/responder_common.c +++ b/src/responder/common/responder_common.c @@ -374,7 +374,7 @@ static void responder_idle_handler(struct tevent_context *ev, goto end; } - if ((now - rctx->last_request_time) > rctx->idle_timeout) { + if (tevent_common_check_signal == 0 && (now - rctx->last_request_time) > rctx->idle_timeout) { /* This responder is idle. Terminate it */ DEBUG(SSSDBG_TRACE_INTERNAL, "Terminating idle responder [%p]\n", rctx); ``` Does this make sense? Another question that I have is why tevent_context does not have a tevent_queue structure that we could just do a `tevent_queue_length` and be happy? :-) Again, please, keep in mind that I may be firing non-sense questions due to lack of technical knowledge on samba side (and here I'll be more than happy to learn more from you). """ See the full comment at https://github.com/SSSD/sssd/pull/511#issuecomment-377480814
_______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org