FDRef
From Erights
Kevin Reid (Talk | contribs) (draft...) |
Kevin Reid (Talk | contribs) (save WIP) |
||
| Line 2: | Line 2: | ||
An [[FDRef]] is an object which wraps the operating system's ''file descriptors'' or similar objects. On platforms which have file descriptors, i.e. small integers naming open files, the primary purpose of FDRef objects is to ensure that a file descriptor is closed after, and not before, there are no users of it (that is, when the FDRef is garbage collected). Therefore, all interfaces to system calls which take file descriptors should either take FDRefs or be methods of FDRef. | An [[FDRef]] is an object which wraps the operating system's ''file descriptors'' or similar objects. On platforms which have file descriptors, i.e. small integers naming open files, the primary purpose of FDRef objects is to ensure that a file descriptor is closed after, and not before, there are no users of it (that is, when the FDRef is garbage collected). Therefore, all interfaces to system calls which take file descriptors should either take FDRefs or be methods of FDRef. | ||
| + | |||
| + | FDRefs are a low-level interface; they reveal nondeterminism, and may be used to directly perform potentially blocking system calls. They should always be wrapped by higher-level facilities, and exist only to be a useful implementation abstraction and to allow writing said wrappers in E. | ||
| + | |||
| + | Since file descriptors may be explicitly closed, it is possible to have a FDRef | ||
==Protocol== | ==Protocol== | ||
| - | When a method is applicable to only certain types of open files (e.g. shutdown only applies to sockets), it may be absent from that particular FDRef object. '''Note''': Due to limitations caused by the implementation platform, it may be the case that a FDRef does not have all of the methods it should for its file type if it was obtained in some “generic” way, or it may have methods which are not applicable. {{XXX|Should we obligate implementing | + | When a method is applicable to only certain types of open files (e.g. shutdown only applies to sockets), it may be absent from that particular FDRef object. '''Note''': Due to limitations caused by the implementation platform, it may be the case that a FDRef does not have all of the methods it should for its file type if it was obtained in some “generic” way, or it may have methods which are not applicable. {{XXX|Should we obligate implementing [[Miranda respondsTo|__respondsTo/2]] to detect the type of file?}} |
| + | |||
| + | {{XXX|finish documenting/specifying}} | ||
| + | |||
| + | {{instance msgdoc|getFD|0||[[int]]}} | ||
| + | Returns the file descriptor. Clients should be extremely careful to retain the FDRef until they are done using the file descriptor. | ||
| - | {{XXX}} | + | {{instance msgdoc|shutdown|2|<var>direction</var> :{{XXX|specify}}, <var>ejector</var> :[[ExitFunc]]|[[void]]}} |
| + | Performs the {{SUSfn|shutdown}} system call, exiting according to <var>ejector</var> if it fails. {{XXX|Explain direction argument. In current impl, it is a CL symbol.}} | ||
[[Category:EIO]] | [[Category:EIO]] | ||
[[Category:ELib specification]] | [[Category:ELib specification]] | ||
Revision as of 04:20, 25 July 2011
- This object type is currently only implemented in E-on-CL.
An FDRef is an object which wraps the operating system's file descriptors or similar objects. On platforms which have file descriptors, i.e. small integers naming open files, the primary purpose of FDRef objects is to ensure that a file descriptor is closed after, and not before, there are no users of it (that is, when the FDRef is garbage collected). Therefore, all interfaces to system calls which take file descriptors should either take FDRefs or be methods of FDRef.
FDRefs are a low-level interface; they reveal nondeterminism, and may be used to directly perform potentially blocking system calls. They should always be wrapped by higher-level facilities, and exist only to be a useful implementation abstraction and to allow writing said wrappers in E.
Since file descriptors may be explicitly closed, it is possible to have a FDRef
Protocol
When a method is applicable to only certain types of open files (e.g. shutdown only applies to sockets), it may be absent from that particular FDRef object. Note: Due to limitations caused by the implementation platform, it may be the case that a FDRef does not have all of the methods it should for its file type if it was obtained in some “generic” way, or it may have methods which are not applicable. XXX Should we obligate implementing __respondsTo/2 to detect the type of file?
XXX finish documenting/specifying
getFD/0
- Signature: getFD() :int
Returns the file descriptor. Clients should be extremely careful to retain the FDRef until they are done using the file descriptor.
shutdown/2
Performs the shutdown() system call, exiting according to ejector if it fails. XXX Explain direction argument. In current impl, it is a CL symbol.
