It seems to me that allowing the poller to fail more gracefully than just calling an abort should fix the problem

I agree that it's probably the best solution.

That said, it puzzles me that you observed the same problem with GFAL2. GFAL2 is not doing any kind of file descriptor handling behind the scene (AFAIK). Now the epoll_create1 is called with EPOLL_CLOEXEC but I don't thing the close-on-exec is subject to race conditions. Any thoughts?

It's been a while since I thought about this but I think gfal2 was only involved because it happened to be the way XRootD was being loaded. I could probably have reproduced it with just xrootd and fork but I stopped once I understood the problem well enough to open this issue.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/1198#issuecomment-856642536", "url": "https://github.com/xrootd/xrootd/issues/1198#issuecomment-856642536", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

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