Currently the gfortran IO library is supposed to be thread safe. Additionally, allowing multiple processes to access the same file could be useful, and if we eventually want to support co-arrays with multiple processes, it will be needed as co-arrays specify that multiple images can access a single file. On POSIX this can be accomplished with the fcntl() syscall. We'd certainly want to make this optional (perhaps with a compiler command-line switch like the fpe options), to avoid the fcntl() overhead as well as frequent buffer flushing in normal single-process usage.
Change severity to enhancement.
Coonfirmed.
Other compilers have the SHARE= specifier for OPEN and INQUIRE, e.g. Intel or HP. I'm not sure it is needed, but one could consider supporting it as well when implementing this option. http://www.intel.com/software/products/compilers/docs/flin/main_for/lref_for/source_files/rflioop.htm I think Fortran 2008 does not allow to such access which makes it a non-issue in terms of the standard, including for coarrays, but still this is a not so rarely requested feature. (But one has to be careful as a user otherwise the program might read/write garbage.)
Some writings arguing that POSIX locking is more or less fundamentally broken: http://0pointer.de/blog/projects/locking.html http://0pointer.de/blog/projects/locking2.html http://www.samba.org/samba/news/articles/low_point/tale_two_stds_os2.html AFAICS, if gfortran is to eventually support multi-image IO in the context of Co-array Fortran as in the TR http://j3-fortran.org/doc/meeting/192/10-166.pdf , it is possible to implement all of this without relying on POSIX locking (fcntl) for synchronization, instead using the existing IPC channels that co-arrays provide. That being said, it might be necessary to do a fcntl lock+unlock at appropriate places in order to force the NFS client to flush dirty bytes to the server; alternatives to using fcntl() to force NFS flushing is fsync or a close+reopen of the POSIX file descriptor. Close+reopen does have the nice property of being portable and not relying on a working NFS locking implementation. FWIW, one strange thing about the 10-166 TR is that there is no mention of stream access, which AFAICS is suited to parallel access just like direct access.
This PR did not get any attention for almost five years. Any point to keep it open?
> This PR did not get any attention for almost five years. Any point to keep it open? No feed-back. Closing as WONTFIX.
The master branch has been updated by Nick Clifton <nickc@gcc.gnu.org>: https://gcc.gnu.org/g:e6cbe9654d14588f8bcaf267730fa4c694216eee commit r10-7841-ge6cbe9654d14588f8bcaf267730fa4c694216eee Author: Stephen Casner <casner@acm.org> Date: Tue Apr 21 10:44:32 2020 +0100 Since the pdp11-aout target does not support gdb, gdbserver or gprof these should be excluded in configure. PR 25830 * configure.ac (noconfigdirs): Exclude gdb & gprof for pdp11. * configure: Rebuild.