Race condition in `AIOFile.open()` about aiofile HOT 4 CLOSED

@h4l I think should trying to add asyncio.Lock. Of course create a PR, I will assist to fix it.

from aiofile.

I intentionally didn't put any locks on it. Here the behavior completely repeats the behavior of the operating system. Usually the user has to take care of opening and closing the file correctly, tell us why you want to open the same instance in different coroutines?

from aiofile.

I use the AIOFile in a class. Its methods which operate on the file assume it may not have been opened, so they await the AIOFile object before using it to ensure it's open. I don't think there's a way to check if an AIOFile was already opened (without poking at the private _file_obj) so my __init__() can't enforce that the file is open when instances are created. And if I opened it in init myself, I'd have to create an asyncio.Task for the async open to handle failures.

I will probably refactor to do the open once in my __aenter__(). I guess I don't really want to open it multiple times, but doing so was the simplest way to ensure it was open, and I didn't expect that doing that would cause this kind of bug.

from aiofile.

Are you happy with the current behaviour, or would you be open to a PR to change it? A few options come to mind:

1. Use a lock so that concurrent open() calls can't result in the actual file being opened more than once
2. Don't lock, but take an optimistic concurrency control approach — after getting a file handle, check again if one was opened while waiting, and don't overwrite the existing FD if so
3. As 2. but raise an error if the file was concurrently opened more than once (assuming you feel it's not a valid use of the API to call open() concurrently)
4. Something else?

I'd be happy to contribute a PR.

from aiofile.