Skip to content

Add operations for obtaining operating-system handles

Wolfgang Jeltsch requested to merge wip/jeltsch/obtaining-os-handles into master

This merge request implements CLC proposal #369. At the same time, it resolves GHC issue #26265.

The interface that this merge request introduces generally follows the one that is suggested in the GHC issue description. It deviates from it in the following ways:

  • The new operations are not part of ghc-internal but of base. They are in a new module System.IO.OS.
    • Public operations should not be offered via ghc-internal, at least not exclusively. If these operations are fundamental, they should be part of base.
    • There is currently no module in base into which the new, rather low-level, operations would fit. Therefore, creating a new module for them and possible future operations of similar kind seems sensible.
  • In the case of a file handle, read and write buffers are both flushed.
    • This is in line with what other handle operations do and is helpful for avoiding data corruption.
  • In the case of a file handle, both read and write access from other agents are blocked.
    • This is virtually inevitable, given how file handles are represented, and is also helpful for avoiding data corruption.
  • There is no operation for obtaining a single file descriptor for reading and writing from a file handle.
    • It would be suboptimal to have an operation that works only with file handles, as the distinction between file and duplex handles is largely an implementation detail. It seems better to first check whether obtaining a single file descriptor for reading and writing is really needed in the wild.
  • There is no operation similar to unsafeHandleToFds.
    • Just obtaining a file descriptor, without running an action on it while further handle access is blocked, is something that can be achieved with the CPS operations as well: by using return as the continuation.
  • Besides file descriptors, also Windows handles can be obtained.
    • It seems to be most plausible to not treat the POSIX I/O manager specially but support the Windows I/O manager too.
Edited by Wolfgang Jeltsch

Merge request reports

Loading