PengZheng commented on code in PR #710:
URL: https://github.com/apache/celix/pull/710#discussion_r1443699476
##########
bundles/remote_services/discovery_zeroconf/src/discovery_zeroconf_announcer.c:
##########
@@ -532,7 +644,8 @@ static void
*discoveryZeroconfAnnouncer_refreshEndpointThread(void *data) {
discoveryZeroconfAnnouncer_handleMDNSEvent(announcer);
}
} else if (result == -1 && errno != EINTR) {
- celix_logHelper_error(announcer->logHelper, "Announcer: Error
Selecting event, %d.", errno);
+ celix_logHelper_error(announcer->logHelper, "Announcer: Error
Selecting event, %d.", errno);
+ sleep(1);//avoid busy loop
Review Comment:
I'm not familiar with this part yet, and thus will only leave my two cents
here.
While `errno == ENOMEM` suggests a temporary failure, for which `sleep(1)`
does make sense, `errno == EBADF` may imply that the bundle could not work any
more, e.g. the `eventFd` or `dsFd` may be accidentally closed by some buggy
code.
We can really do nothing locally to recover from this kind of error. This
represents some long lasting exceptional system condition, which can luckily be
modeled using Celix condition. Once some outside watchers get notified of this
system exception, he/she can try to restart the bundle, which could fix the
accidentally closed fd in this case.
I think generic system exception is a generally useful concept, which
further extends error code and C++ exception. Combined with RSA, this means
these exceptions can be watched remotely (cool). Event better, we don't need
descriptors for Remote Celix conditions because they have no methods.
WDYT? @pnoltes @xuzhenbao
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
