Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
So, in fact, both code path so exactly the same thing if there is no error. However, there is a big difference when close returns an error. The object then gets on the delayed destroy queue with the ref count being 0. That means delayed destroy will try to re-close the file. Since the file object is in an undefined state it's not clear whether or not this will have any bad side-effects. Perhaps @simonmichal can comment on this.
If the XrdCl::File is in an error state the close will be failed right away (without sending the request):
https://github.com/xrootd/xrootd/blob/38112a935133ff23fce302d61e166b2d4194449a/src/XrdCl/XrdClFileStateHandler.cc#L976-L980
Now, the only problem with deleting a XrdCl::File object which cannot be closed is that there might be some outstanding requests on that object. I could add a method for you that allows to check if there are any in-the-flight requests, or I could add a method that allows you to register a callback to be called once all the outstanding requests have been cleared.
It can happen that async posix read handler decides to drop the outstanding reads when they are delayed beyond certain timeout and call this Close() regardless of that.
In the presence of outstanding read requests the close will fail by definition.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1