FDRef
From Erights
m (link to info about choice of “open file”) |
Kevin Reid (Talk | contribs) (draft...) |
||
Line 1: | Line 1: | ||
:''This object type is currently only implemented in [[E-on-CL]].'' | :''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 | + | 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. |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
==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 {{msg|respondsTo/2}} to detect the type of file?}} |
- | + | ||
- | {{ | + | |
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | ||
- | + | {{XXX}} | |
[[Category:EIO]] | [[Category:EIO]] | ||
[[Category:ELib specification]] | [[Category:ELib specification]] |
Revision as of 04:09, 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.
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