 |
 |
Hi Andy, Yes, we want to throw it away :) We have a mini-test with async read + condition variable running so we'll know soon if there's any issue implanting this into the proxy code. Matevz On 03/17/14 19:00, Andrew Hanushevsky wrote: > 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