 |
 |
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. 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 >> >> >