 |
 |
Hi Matevz, The answer is driven by how important is the pending data? If it's important then it should be allowed to be added to the cache set even when the file is closed. If it's not important then it can be thrown away with impunity. Throwing away data here is far easier than trying to keep it. You can mark your prefetch object as dead and safely delete the file object (the prefetch object would have to delete itself eventually after it threw away the last piece of data, I assume). Otherwise, yes, we would need to add a "Delete()" method that could delay the actual destruction of the object. Note that the object would need to remove itself from the file table but otherwise delay freeing memory. Answers your question? Andy -----Original Message----- From: Matevz Tadel Sent: Monday, March 17, 2014 6:33 PM To: Andrew Hanushevsky ; xrootd-dev Subject: Re: XrdCl interrupting sync read Hi Andy, OK, I see ... then we're back to the discussion you and Alja had a week ago about XrdPosixFile destruction in caching proxy :) We can try to bypass this problem with async reads (and tell ResponseHandler object to discard the result and auto-destruct when) or you can help us to delay the destruction. Or we try both. What do you think is better? What happens now is that when we shut down X-hundred clients simultaneously, some of them take quite a long while to die -- we've already shortened this significantly by removing in-memory blocks from the write queue but there are horrible outliers in prefetch-read, too (30s) -- the problem is that many prefetching threads need to be notified at the same time that they should stop -- and they aren't so "prefetching" goes on for a long while. Matevz On 3/17/14 3:37 PM, Andrew Hanushevsky wrote: > Hi Matevz, > > The current way the new client works is that close() returns an error if > there > are any outstanding operations. The way I get around that is to keep track > of > the current outstanding operations and when I need to "get rid" of the > file, the > higher level "close()" returns a success and the object is placed in the > background and the real close happens when all of the outstanding > operations > complete. I don't know of any way to cancel an outstanding operation. > > Andy > > -----Original Message----- From: Matevz Tadel > Sent: Monday, March 17, 2014 2:37 PM > To: Andrew Hanushevsky ; xrootd-dev > Subject: Re: XrdCl interrupting sync read > > Hi Andy, > > On 03/17/14 14:26, Andrew Hanushevsky wrote: >> Hi Matevz, >> >> All of xrootd avoids signals like the plague . The only exceptions is >> server-side async I/O where it's required for portability. Then again, of >> late, >> everyone turns that capability off. Anyway, signals aren't really needed >> any >> more and just produce a lot of obtuse difficult to maintain code. So, I >> don't >> see any way you can do this using signals but Lukasz may have a way of >> doing >> this otherwise, However why are you using sync reads anyway? If this is a >> problem you should be using async reads. > > No, we'll do async reads :) I know signals and thread-cancellation are a > sure > road into hell. > > Then, what happens when XrdCl::Close() is called in one thread? Will > current > reads fail? Or will Close() wait for dispatched transactions to complete? > > Matevz > >> Andy >> >> -----Original Message----- From: Matevz Tadel >> Sent: Monday, March 17, 2014 2:19 PM >> To: xrootd-dev >> Subject: XrdCl interrupting sync read >> >> Hi, >> >> I tried to figure out how sigs are masked and handled in xrootd -- but >> they >> don't seem to be used at all (or they are wrapped very well :) ) -- so >> maybe the >> whole thing below is a nono. >> >> Is it safe to signal a thread doing a synchronous XrdClFile::Read() to >> make it >> come back with the equivalent of EINTR? What signal should I use for >> that? >> >> The thread is owned by me ... so I can install signal handlers if it's >> needed. >> >> Cheers, >> Matevz >> >> ######################################################################## >> 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 > > ######################################################################## > 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 ######################################################################## 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