 |
 |
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