async_open doesn't fully mimic the behavior of Python file objects
ilookhandsometoday opened this issue · 5 comments
The object that is produced by async_open has a seek() method. However, it only accepts two positional arguments(one being the object itself, and the other being the offset), while Python files accept three positional arguments (including the object itself), the third being the position, from which the offset has to be applied (0 - beginning, 1 - current position, 2 - end of file). This leads to some conflicts between this module and other modules that rely on the default Python file interface. Will this ever be changed?
@ilookhandsometoday in the normal case, the operating system seek to the beginning or end of the file, however, when using the asynchronous API, there is no guarantee that the file has not changed in another coroutine and has not grown. Don't rely on size either.
This library mimics the usual synchronous API, and offset is a virtual, just a number in the class instance.
@ilookhandsometoday in the normal case, the operating system seek to the beginning or end of the file, however, when using the asynchronous API, there is no guarantee that the file has not changed in another coroutine and has not grown. Don't rely on size either.
This library mimics the usual synchronous API, and offset is a virtual, just a number in the class instance.
The synchronous Python API has the same problem when the file object is used in several threads.
UNIX has a smaller problem (file size being changed) when file descriptor is duplicated via dup(2) of the process is cloned via fork/vfork/clone, or when some other process changes the file.
Somehow, both Python API and UNIX API are used with quite a bit of success.
I'd argue that what @ilookhandsometoday wants, is ultimately for this library to issue lseek(2) on the underlying file descriptor.
@dimaqq the point here is that this will be an emulation, no really guarantee of compatibility, and how is this different from just reading the entire remaining file by looking the size?
The requested operation takes place at the absolute
position in the file as given by aio_offset, as if lseek() were
called immediately prior to the operation with an offset equal to
aio_offset and a whence equal to SEEK_SET.
https://man7.org/linux/man-pages/man3/aio_read.3p.html
This is a limitation of the operating system API.
(I've only checked Linux, other OS may vary.)
I'm proposing to close the issue as "impossible today".
To be honest with you all, at this point I don't even remember why I've opened this issue. I did get some useful info on the intricacies of working with files, I guess, so it was not all in vain. Thank you for your time!