 |
 |
On Mar 1, 2011, at 3:41 AM, Lukasz Janyst wrote: > Hi Brian, > > the fork safety code has been run in Alice production environment > for around a week without any visible problem, it's been also > successfully run in EOS, so if you confirm that it doesn't break > anything for you I feel confident to commit it. I will also add a flag > to the environment to explicitly enable the fork handlers. Yes, please feel free to commit it. Is it also possible to manipulate this flag *not* through the environment? I.e., through some API setting? CMSSW isn't allowed to monkey around with the environment. Brian > They will > be disabled by default in order not to break the code of people who > run some stuff in fork/execve mode. > > Cheers, > Lukasz > > 2011/2/7 Lukasz Janyst <[log in to unmask]>: >> Ok, thanks for the feedback. I hope to have it committed at the end of >> this week or at the beginning of the next one if there is no nasty >> surprises by then. >> >> Lukasz >> >> On Mon, Feb 7, 2011 at 4:39 PM, Brian Bockelman <[log in to unmask]> wrote: >>> >>> On Feb 7, 2011, at 9:26 AM, Lukasz Janyst wrote: >>> >>>> Hi Brian, >>>> >>>> no, it did not. Since it is quite a significant change to the thread >>>> handling code, I want to have it properly tested first. We have asked >>>> Alice whether they could do that in their software and I would also >>>> like to see it running for a couple of days in our EOS dev instance. >>>> What about your experiences: have you managed to run it on something >>>> else than some toy examples? >>>> >>> >>> Hi Lukasz, >>> >>> I've tried doing a slow-copy of a few ROOT files; this tests a pretty wide range of Xrootd commands (Read, ReadAsync, ReadV, open/close files). That's about as thorough a test we'll have in CMS until reconstruction switches to the forking mode. >>> >>> For testing the patch in non-forking mode: we have committed it to the dev versions of CMSSW, so it'll be run through our release validation suite nightly and T0 workflows every Wednesday. >>> >>> Brian >>> >>> >>