Hi Matevz,
The reason is that I chose ioActive() is simply that I thought we would
keep the code that destroys the posix object the same in close() and
execute it if we could do so immediately or schedule a thread to do a
defer close. In any case, the code (as it does now) at the very least
removes the FD from the fd table. Then again, looking at the code changes
I do get a little confused. I suppose I would say keep the old logic as
close as to the original with minimal changes to solve this.
Andy
On Mon, 24 Mar 2014, Matevz Tadel wrote:
> Hi Andy,
>
> I vote for
>
> bool initiateClose();
>
> as this makes it clear that Close() will be called in a jiffy and that
> irreversible state changes might occur in the object. ioActive() sounds like
> something that can be called several times without changing the object.
>
> But ... you're the master so please just pick what you think is consistent
> with the rest.
>
> Matevz
>
> On 03/24/14 12:54, Andrew Hanushevsky wrote:
>> 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
>
########################################################################
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
|