Print

Print

One additional observation. To get around this fork handler problem in a compatible way one could introduce a new envar (you could potentially piggy back on the existing one) which tells the client why you want to run the fork handler. The two values would be "for_exec" or "for_client". When "for_rexec" is set the client side of the fork handler does not start any new threads which means it would not create a poller. The "for_client" setting would do what it does today. The default is controversial. Obviously, CMS and some ATLAS jobs do "for_client" as a way to run psudeo multi-threading for code that is not thread safe. Others, like Chris do "for_exec" and need the option to reliably do so. So, perhaps "for_client" would be least controversial but at least one would have a way to get around this problem.

—
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-857040556", "url": "https://github.com/xrootd/xrootd/issues/1198#issuecomment-857040556", "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