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
|