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