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