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
