 |
 |
With a power outage at Cornell and the Thanksgiving break this weekend, I haven't had a chance to trace down all the threads that were spawned while I used the XrdClient interface. However, I was able to find several more 'features'. Memory Leaks XrdClientConnMgr::Connect() if the connection fails, then physical and logical connections created are leaked. Both logconn and phyconn should be deleted before line 274. The destructor for XrdClientPhyConnnection should delete all entries in fMsgQ XrdClientConn::ReadPartialAnswer line 703, Xmsg should be deleted. XrdClientConn::ClientServerCmd: In the loop between 235 and 258, the value of xmg retrieved from one iteration of the loop to the next is leaked. So need to do a 'delete xmg' right before line 238. These memory leaks could be avoided by using auto_ptr<> through out the code. Inefficiency Almost all member methods that take XrdClientUrlInfo as a parameter, take that parameter by value instead of using a 'const XrdClientUrlInfo&'. So every time one of these routines is called, a new XrdClientUrlInfo must be created. As an XrdClientUrlInfo holds several XrdClientStrings there is a lot of memory copying to be done. Design Question Different XrdClientLogConnection can share the same XrdClientPhyConnection, but how do the XrdClientPhyConnection know which message is for which XrdClientLogConnection? Chris Jones