 |
 |
> 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 or view it on GitHub: https://github.com/xrootd/xrootd/pull/1724#issuecomment-1165331785 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## 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