Hi Alja,
Well, if that is the simplest way to do it then let's go ahead with that.
I assume th I/O pending state is quite dynamic and can't really be easily
handled by some simple flag. So, let's go with something like:
bool ioActive();
which returns true that triggers a delayed close and false which allows
the caller to do an inline close. If there is more than just active I/O
that can place the object is a non-closeable state then we should use a
more generic name (e.g. isCloseable()). What do you think?
Andy
On Sun, 23 Mar 2014, Alja Mrak-Tadel wrote:
> Hi Andy,
>> I was wondering if there was a way to structure this so that a thread is
>> run to destroy the file object only if a file cache is being used. I'd
>> rather not add the thread overhead to things like fuse and a non-caching
>> proxy server. As for reusung a worker thread, while a good idea, we really
>> don't have access to them. Something to think about. I'll see how difficult
>> it would be. In any case, even if I could provide access to the thread
>> pool, there won't be one if the posix interface is being used outside of
>> xrootd, so the code would have to have two paths in any case.
>>
> How about adding a new virtual XrdOucCacheIO function that checks if
> destruction of XrdPosixFile needs to be delayed (e.g. InitiateClose(),
> RequiresDelayedClose(), TryClose() ...)? The return value of this function
> determines if a new thread is needed to run the real Close(). In this
> function I will prevent issuing any new read requests so it has to be
> guaranteed that the real Close() is called immediately after that.
>
> Alja
>
>> On Fri, 21 Mar 2014, Alja Mrak-Tadel wrote:
>>
>>> Hi Andy,
>>>
>>> I had to move destruction of XrdPosixFile into separate task to avoid long
>>> lock in XrdOfsHandle::Alloc() and XrdOfsHandle::Retire(). This is the
>>> change which fixed the problem:
>>> https://github.com/alja/xrootd/compare/pd
>>> You might want to reuse existing worker threads instead. One of the
>>> XrdClFile::Close() calls is also removed.
>>>
>>> We also made improvements in XrdFileCache module. We need a day or two to
>>> close up changes and test them.
>>>
>>> Alja
>>>
>>>
>>>
>>> On 03/20/14 13:33, Andrew Hanushevsky wrote:
>>>> Hi Matevz,
>>>>
>>>> Hmmmm, ok you need to give me specific details on what you want done.
>>>>
>>>> Andy
>>>>
>>>> On Thu, 20 Mar 2014, Matevz Tadel wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> Alja and I would like to push in some changes for the XrdFileCache. We
>>>>> have our own workaround for destruction of XrdPosixFile /
>>>>> XrdOucCacheIO in a special thread ... Andy will probably want to
>>>>> implement this for us so he stays on top of things.
>>>>>
>>>>> We should be good to go early next week.
>>>>>
>>>>> Cheers,
>>>>> Matevz
>>>>>
>>>>>
>>>>> On 03/20/14 10:04, Lukasz Janyst wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> I have done all the coding that was on my list. I have two items
>>>>>> left:
>>>>>>
>>>>>> 1) packaging - in the process of being done - consulting with Mattias
>>>>>> to
>>>>>> integrate with EPEL. I have some draft specfiles, but probably need
>>>>>> two or three
>>>>>> more iterations.
>>>>>>
>>>>>> 2) the server is broken when compiled in C++11 mode. It didn't seem
>>>>>> to respond
>>>>>> when I tested it three months ago, so perhaps the issue is fixed now,
>>>>>> needs
>>>>>> testing. Andy, can you please check whether this is still the case?
>>>>>> You can use
>>>>>> my testing cluster.
>>>>>>
>>>>>> Cheers,
>>>>>> Lukasz
>>>>>>
>>>>>> ########################################################################
>>>>>> 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
>>>>>
>>>>> ########################################################################
>>>>> 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
>>>
>>
>> ########################################################################
>> 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
|