Gr.file_descriptor_* and close()


#1

Hi,

it’s just a nitpick, really, but I’d like to vote for chucking out the
close() calls in gr.file_descriptor_{sink,source} (in the destructors).

I’ve been working with these blocks for talking across pipes, and I
constantly run into warnings because files get closed when I don’t want
them to. So far, it hasn’t caused any errors, but the reason my code
gets confused is because when I use a named pipe, I have to open it in
one thread and pass the fileno to the GR block. The block, however,
closes the file on destruction, leaving a dangling file ID in the
calling thread.

As I said, it’s nothing that can’t be caught, but I’d prefer it if the
open() and close() calls happened in the same scope and thread - I’ve
patched my own copy accordingly and find it much easier to use. As far
as I can tell, no code in the trunk would be affected.

MB


#2

On Fri, May 08, 2009 at 11:13:22AM +0200, Martin B. wrote:

closes the file on destruction, leaving a dangling file ID in the
calling thread.

You can avoid this problem by passing the result of
os.dup(file_descriptor) to gr_file_descriptor_*.

Eric