[PATCH 1 of 3 RFC] scmutil: support background file closing

[Pierre-Yves David]

On 01/04/2016 08:12 PM, Gregory Szorc wrote:
> On Mon, Jan 4, 2016 at 11:11 AM, Bryan O'Sullivan <bos at serpentine.com
> <mailto:bos at serpentine.com>> wrote:
>
>
>     On Sat, Jan 2, 2016 at 7:15 PM, Gregory Szorc
>     <gregory.szorc at gmail.com <mailto:gregory.szorc at gmail.com>> wrote:
>
>               def __call__(self, path, mode="r", text=False,
>         atomictemp=False,
>         -                 notindexed=False):
>         +                 notindexed=False, filecloser=None):
>                   '''Open ``path`` file, which is relative to vfs root.
>
>                   Newly created directories are marked as "not to be
>         indexed by
>                   the content indexing service", if ``notindexed`` is
>         specified
>                   for "write" mode access.
>         +
>         +        If ``filecloser`` is passed, it will be used to close the
>         +        opened file. ``filecloser`` only works if the file is being
>         +        used as a context manager.
>
>
>     This comment is a bit misleading, as filecloser will only be used on
>     Windows. That futher suggests to me that filecloser shouldn't even
>     be made available to callers, as it's purely an OS-specific workaround.
>
>
> I experimented with fully abstracting away the async file closing.
> Basically, I created a "asyncvfs" layer that automagically did things
> asyncronously. It quickly became apparent that some caller cooperation
> is needed otherwise the implementation quickly becomes complicated. For
> example, attempting to automatically do async closes opens up the
> possibility for race conditions between closing a handle with unflushed
> writes and opening it again. You either need to build a lot of
> complexity into the async layer to prevent races or you need to put the
> caller in charge. The abstracted complexity is robust and more proper,
> but it is really a bit of work. I figured it would be easier to put the
> caller in charge.

Can't we have some thread safe collection of file to be closed that file 
opener checks before proceeding forward ?

-- 
Pierre-Yves David