On Thu, 2014-07-17 at 17:22 +0200, Giovanni Campagna wrote:
2014-07-03 12:03 GMT+02:00 Philip Withnall <philip tecnocode co uk>:Hey, I am thinking about doing static analysis of file descriptor operations in Tartan[1], and for that I need a way to identify file descriptors in function parameters and return values (and properties and signal parameters too). I can think of two options for this: 1. An (fd) annotation which marks an integer as a file descriptor. 2. A new type, GFileDescriptor, defined as typedef int GFileDescriptor and applied to all the relevant APIs with a (type) annotation. Both options could be used with (transfer) to indicate ownership transfer of the FD.Unlike memory, FD transfer is often dynamic: GUnixInput/OutputStream (which are the most common way to interact with a FD in a introspected language) accept a close_fd property, so they either eat or not eat their FD.
I’d forgotten about the close-fd property, that’s a pain. I think for static analysis, I will have to abort the analysis if the close-fd property is set to a non-constant value anywhere in the code. That’s probably OK; I assume that in most cases, the property isn’t used, and in most of the cases where it is, it’s set to a constant value. That just means Tartan will have to hard-code some knowledge about GUnix[Input|Output]Stream.
I think I’m favouring option 2 because file descriptors aren’t really integers in any of the normal senses — you can’t really do arithmetic on them, and any comparison between them (except equality) is useless. So as far as introspection is concerned, they shouldn’t be integers.But existing bindings assumes they are integers, so while a special type is useful at the g-i level, in pratice they would keep being exposed as integers in the languages (like we do for enums).
Perhaps the (fd) annotation would be best then, since that wouldn’t affect existing bindings.
I’d appreciate other people’s thoughts on this. I suspect that a feature like this could be used in bindings to automatically close open FDs when they go out of scope. Is that done already somehow?In languages with a GC, this would be tied to a GC cycle, and by the time that runs, the FD limit probably has been reached already. FDs need to be closed explicitly (not to mention error handling that should happen around closing, and the fact that closing blocks)
I’m not sure. Of course, FDs should be closed explicitly, but many languages do automatically close them as they go out of scope as a safety feature. For example, Python will close an FD when the owning file object goes out of scope (it’s done in the file’s __del__ method). However, this won’t work with FDs transferred from C code, unless the GLib Python bindings automatically wrap the FD in a file object. So an (fd) annotation might make implementing that easier. Is that right? I have little knowledge of the Python bindings. Philip
Attachment:
signature.asc
Description: This is a digitally signed message part