Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
I did understand after rechecking DelayedDestroy. Detach() can only be called once, no matter what. However, the code alternative is equivalent to the simpler original suggestion. Here is what the equivalence is:
a) fP->Ref();
if (fP->XCio->Detach((XrdOucCacheIOCD&)*fP)) fP->Unref();
if (fP->Refs() < 2)
At this point is Refs() is 1 then it must be due to the Ref() we just issued. So, it must be less than 2. Hence close can occur because we are the only ones holding the ref count.
b) fP->Ref();
if (fP->XCio->Detach((XrdOucCacheIOCD&)*fP)) {
fP->unRef();
if (fP->Refs() == 0) {
At this point if Refs() is 0 it must be due to the Unref() we just issued (i.e. the count was 1 and <2 and now is 0). Hence close can occur because no one is holding the ref count (minor semantic quibble).
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.
—
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