Can't open($newfh, $mode_layers, '&' . fileno($fh))

renodino has asked for the wisdom of the Perl Monks concerning the following question:

(on WinXP, AS 5.8.6)

I'm trying to come up with a generic way to pass filehandles between threads (wo/ having a priori knowledge of the filehandle's modes/layers). The only way I know of is to pass the fileno, and re-open in the receiving thread using open(FH, "&$fileno").

2 questions:

1) How can I get the open()'d modes for a filehandle on Win32 ? fcntl() doesn't work there, and I can't seem to find a Win32 module to do it...

2) I need to be able to re-apply the access modes and PerlIO layers in the recving thread. I can get the layers via PerlIO::get_layers(), and (hopefully) I can get the modes via a Win32 call (or via fcntl() everywhere else).

However, when I try to apply layers to a fileno open(), Perl barks in 2 arg open(), and creates a new file in 3 arg open().

use PerlIO;

my $fd;
open($fd, '+>>:raw', 'somefile.data') || die $!;

my $layers = ':' . join(':', PerlIO::get_layers($fd));

print "$layers\n";
#
# this creates a new file named "&3"
#
my $fn = fileno($fd);
my $fd2;
open($fd2, '+>>' . $layers, '&' . $fn) || die $!;
#
# this dies with "Invalid argument at filemode.pl line ..."
#
my $fd3;
open($fd3, '+>>' . $layers . ' &' . $fn) || die $!;

close $fd;
close $fd2;
close $fd3;
[download]

Is there any way around this problem ?

Comment on Can't open($newfh, $mode_layers, '&' . fileno($fh)) Download Code

Replies are listed 'Best First'.
Re: Can't open($newfh, $mode_layers, '&' . fileno($fh)) by Errto (Vicar) on Feb 10, 2006 at 21:26 UTC
Looks like there's two issues here. One is that in the three-arg form of open, the '&' character goes at the end of the second argument, not the beginning of the third one. The proper syntax would be `open($fd2, '+>>&', $fn);` Your code as is opens a file called `&3` with $fd2 pointing to it. The other is that, based on a quick test here, it seems that you cannot specify PerlIO layers when opening a filehandle this way. But binmode should be able to help with that.	[reply] [d/l] [select]
Re^2: Can't open($newfh, $mode_layers, '&' . fileno($fh)) by renodino (Curate) on Feb 10, 2006 at 21:51 UTC
OK, thnx for the pointers wrt '&' placement. However, testing binmode() seems to do some odd things; if I apply the layers of the original to the dup'ed handle, the layers stack, rather than replace: `use PerlIO; my $fd; open($fd, '+>>:raw', 'somefile.data') \|\| die $!; my $layers = ':' . join(':', PerlIO::get_layers($fd)); print "$layers\n"; # # this doesn't complain, but the layers aren't being properly applied # my $fd3; open($fd3, "+>>&", fileno($fd)) \|\| die $!; binmode $fd3, $layers; print join(',', PerlIO::get_layers($fd3)), "\n";` [download] results in "unix,crlf,unix" as the reported layers for $fd3. I guess its possible scan and apply layers - but how do I remove them ? I tried using just "binmode $fd3;", and that still reports unix,crlf... And I'm still left in limbo wrt getting handle access modes on Win32...is there any Win32API solution to that ?	[reply] [d/l]
Re: Can't open($newfh, $mode_layers, '&' . fileno($fh)) by BrowserUk (Patriarch) on Feb 11, 2006 at 17:01 UTC
1) How can I get the open()'d modes for a filehandle on Win32 ? fcntl() doesn't work there, and I can't seem to find a Win32 module to do it... From what I can tell, this isn't a Win32::API problem, more a CRT problem as the rules regarding open modes are imposed/enforced by the CRT (or possibly the PerlIO layer if you're using that). There does not appear to be anything in the VC++ CRT library for retrieving the open mode from an existing open file. Once you've dup()'d a file, you have to associate it with a FILE* stream, and Perl's open does not provide a mechanism for doing this without also supplying the mode--probably because there is no mechanism in the CRT for re-constituting a stream with it's original mode. About the best you could do is use '+>' and position the pointer at the end-of-file to cater for an original append mode and hope/assume that if the user wishes to read from or write to any other position in the file, they will do a seek first. This leaves one hole in the logic. If they originally opened it '+>>', the docs say that all writes will go to the end of file regardless of whether there have been intervening reads at other positions. If the programmer is relying on this behaviour, (he's probably unwise if he does), then he could be caught out. Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal? "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]
Re^2: Can't open($newfh, $mode_layers, '&' . fileno($fh)) by renodino (Curate) on Feb 11, 2006 at 18:23 UTC
After a solid 8 hours spent chasing this issue (and the other issue RE: mixing layers and fileno open()'s), I've come to a similar conclusion. So I've thrown in the towel on trying to transparently marshal handles between threads. While not a catastrophic loss (since app-specific marshalling is always possible), it is a frustrating situation. I suppose a heavyweight solution might wrap handles in their own apartment thread, and proxy all the operations (ala DBIx::Threaded), but I reckon there be dragons there as well...	[reply]