You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
@abh3: few comments from my side:
First of all, thanks for pointing out that the poller thread needs to exit when the error condition is detected, this is fixed: cd7856c
https://github.com/xrootd/xrootd/blob/cd7856cdf776c668bf51124952bbd3c0ea07f0e0/src/XrdSys/XrdSysIOEventsPollE.icc#L217-L222
There is no way to know if the process is being forked to do an exec or no. Also adding an envar defeats the purpose of the patch, if we want to force the user to play with envars we can simply ask him to disable the fork handler, but this is not the point.
What we are trying to fix here is really not a flaw in the fork handler but in the poller, a bottom component should simply not handle errors with an abort. Roughly speaking, in case of forking for exec it really doesn't matter what happens in the new process before the exec as long as it is not killing the process ;-)
What we need (IMHO) is a way to let the client know that the event loop is not working and that's what the patch does. The overhead of the check is negligible and I wouldn't worry about it.
I really would like to avoid handling errors other than EBADF with the abort as this will make the code incomprehensible.
All that said, if I would be 100% sure that the patch is correct I wouldn't ask you for a review ;-) so here's my main concern, let's say the client is running in the context of XCache and epoll_wait yields an error, the client will start failing all request with fatal error making the cache unusable and in this case, well it would be better to terminate ...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1