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
|