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