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

[Gregory Szorc]

On Mon, Jan 4, 2016 at 11:11 AM, Bryan O'Sullivan <bos at serpentine.com>
wrote:

>
> On Sat, Jan 2, 2016 at 7:15 PM, Gregory Szorc <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.

I suppose this could be slightly more abstracted. For example, we could
hide the background closer in the vfs instance. e.g.

with vfs.startbackgroundfilecloser():
    with vfs('foo', backgroundclose=True) as fh:
        ...

Is this more appetizing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20160104/6e2b0310/attachment.html>