 |
 |
Hi Chris, OK, I completely misunderstood the context of the problem. Indeed, this is very messy and very difficult (and sometimes impossible) to solve. If you could do all your forks before calling any root code it would make life obviously simple. The next obvious question is that if you are running the exact same executable, why not exec it to get a clean copy? It doesn't prohibit any information passing from parent and sure simplifies things at a very low overhead. That said, solving the issue in XrdClient (even if it's possible) won't solve any remaining issuese in the rest of the root package. Andy ----- Original Message ----- From: "Chris Jones" <[log in to unmask]> To: "Andrew Hanushevsky" <[log in to unmask]> Cc: "Lukasz Janyst" <[log in to unmask]>; "Brian Bockelman" <[log in to unmask]>; "xrootd-dev" <[log in to unmask]>; "Philippe Canal" <[log in to unmask]> Sent: Tuesday, November 23, 2010 1:44 PM Subject: Re: Fork safety of XrdClient > Hi Andy, > In CMS, we fork but do not exec since we do run multiple instances of the > exact same executable. This was the case Brian was alluding to. > > Sorry, > Chris > > Christopher Jones > Fermi National Accelerator Laboratory > [log in to unmask] > > On Nov 23, 2010, at 3:31 PM, Andrew Hanushevsky wrote: > >> Hi Lukasz, >> >> I agree with you completely that if the client wants to fork() and >> continue without doing an exec() it becomes quite problematic (as you >> pointed out in another mail file) and very dificult to keep everything >> consistent and clean (doable but a whole lot of effort). On the other >> hand, I was simply pointing out that the complete solution may very well >> be over-kill. Most (and probably all in root) forks are follwed by exec() >> with no reference to anything. I can't think of one case in the root >> framework where that is not the case. If we approach the problem this >> way, then the solution is fairly straight-forward and I suspect would >> solve 99.9999% of the use cases. >> >> Andy >> >> ----- Original Message ----- From: "Lukasz Janyst" <[log in to unmask]> >> To: "Andrew Hanushevsky" <[log in to unmask]> >> Cc: "Brian Bockelman" <[log in to unmask]>; "xrootd-dev" >> <[log in to unmask]>; "Philippe Canal" <[log in to unmask]>; >> "Chris Jones" <[log in to unmask]> >> Sent: Tuesday, November 23, 2010 2:45 AM >> Subject: Re: Fork safety of XrdClient >> >> >>> It's far from being trivial in any case. You also have to consider the >>> fact that the client is multi-threaded and on fork only one thread is >>> "copied" so you have to deal with mutexes and memory inconsistencies. >>> >>> Lukasz >>> >>> On Mon, Nov 22, 2010 at 10:38 PM, Andrew Hanushevsky <[log in to unmask]> >>> wrote: >>>> Yes, but these were opened by the xrdclient framework and they can be >>>> just >>>> as easily manager by setting "fd close on exec flag" which is more >>>> portable >>>> (unless there is some need to not do an exec -- but then there are a >>>> whole >>>> other set of issues that crop up). My point was that there is "general" >>>> solution here. >>>> >>>> Andy >>>> >>>> ----- Original Message ----- From: "Lukasz Janyst" <[log in to unmask]> >>>> To: "Andrew Hanushevsky" <[log in to unmask]> >>>> Cc: "Brian Bockelman" <[log in to unmask]>; "xrootd-dev" >>>> <[log in to unmask]>; "Philippe Canal" <[log in to unmask]>; >>>> "Chris >>>> Jones" <[log in to unmask]> >>>> Sent: Monday, November 22, 2010 11:55 AM >>>> Subject: Re: Fork safety of XrdClient >>>> >>>> >>>>> On Mon, Nov 22, 2010 at 8:35 PM, Andrew Hanushevsky >>>>> <[log in to unmask]> wrote: >>>>>> >>>>>> P.S. atfork() is relatively useless since you don't know what >>>>>> outstanding >>>>>> descriptors should really be closed at that point. >>>>> >>>>> Well, they are all known to the ConnManager, aren't they? >>>>> >>>>> Lukasz >>>>> >>>> >>>> >> >