 |
 |
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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/1198#issuecomment-857040556 ######################################################################## 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