Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re^3: Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE (sources)

by tye (Cardinal)
on Dec 01, 2012 at 01:35 UTC ( #1006551=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE (sources)
in thread Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE

Ah, thanks. _PROTECT_FROM_CLOSE does a lot more than that ("If this flag is set, calling the CloseHandle function will not close the object handle"). But if 'exec' doesn't have its own flag for "don't close upon exec", I could see implementing it this way (and can see some problems that such a choice presents).

I was conflating the "don't close when creating a subprocess" with the "don't close when exec()ing cases". But then, Windows doesn't have fork() nor exec() so there really is only the "don't close when creating a subprocess", which is what _INHERIT is for. (Perl's exec on (non-Cygwin) Windows actually creates a subprocess and then has the parent process exit.)

Perhaps you should be setting _INHERIT instead?

Also, your code doesn't appear useful for the use-case you proposed. You don't want some "Console" handle for talking over some protocol, surely. So write some code that creates a pipe or uses a socket and then try to give that file descriptor to the child (probably using _INHERIT not _PROTECT_FROM_CLOSE, I would bet) and see how that works.

Indeed, the point of including SetHandleInformation() in Win32API::File was exactly for the purpose of letting other programs use handles that your Perl script opened. I think how I've done that successfully in the past was via _INHERIT, but, to be honest, I'm not completely sure at the moment.

Please let us know how it works out.

- tye        


Comment on Re^3: Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE (sources)
Re^4: Win32API::File not setting HANDLE_FLAG_PROTECT_FROM_CLOSE (sources)
by Yary (Scribe) on Dec 05, 2012 at 13:20 UTC
    Hi & thanks for persisting. I'm going to post the working UNIX version of the entire program chain, with its debugging statements, for reference.
    call_with_3.pl
    #!/usr/bin/env perl use warnings; use strict; use Fcntl qw(F_GETFD F_SETFD FD_CLOEXEC); open my $fh,">&2"; unless (@ARGV && $ARGV[0] eq 'noset') { fcntl($fh, F_SETFD, ~FD_CLOEXEC) or die "Can't set flags: $!\n"; print "Set no close on exec\n"; } $ENV{myfd}=fileno($fh); system 'print_to_3.pl'; print $fh "This is to fd $ENV{myfd} from the parent\n";

    print_to_3.pl

    #!/usr/bin/env perl use warnings; use strict; open OUT,">&=$ENV{myfd}" or die "cannot dup $ENV{myfd}: $!\n"; print "Child opened FD $ENV{myfd}\n"; my $p=print OUT "***\nHere is data going to fd $ENV{myfd}\n***\n"; warn "return value of print=$p ($!)\n";
    I'm copying the child's 3rd FD to STDERR- in real life I will want to move the child's 3rd FH to STDIN, and the child's stdin & stderr to filehandles the parent can read from, but I don't want to get bogged down in more details here.

    The above is what got me wanting to set _PROTECT_FROM_CLOSE. If you run ./call_with_3.pl noset the pair of programs fail, you have to protect FD 3 from going away when the child exec's into a new process.

    Windows doesn't really fork, it emulates it with a thread running a copy of the interpreter, so I can believe it won't need _PROTECT_FROM_CLOSE. On the other hand, _INHERIT is already set, hence the flags was=1 debug output, so that isn't the issue.

    Here's the pair of programs modified for Windows. The outer program is most of the code already posted, with even more debug info.
    call_with_3.pl

    #!perl -w use strict; use Fcntl qw(F_GETFD F_SETFD FD_CLOEXEC O_TEXT); use Win32API::File qw(:Func :HANDLE_FLAG_); use Win32::Process; open my $fh,">&2"; $^F = 3; my $os_handle=GetOsFHandle($fh) or die "Can't GetOSFHandle: $^E,\nstop +ped"; #$ENV{myfd}=my $ivFD = OsFHandleOpenFd($os_handle,O_TEXT); GetHandleInformation($os_handle, my $flags); print "HANDLE_FLAG_INHERIT=",HANDLE_FLAG_INHERIT,"\n"; print "HANDLE_FLAG_PROTECT_FROM_CLOSE=",HANDLE_FLAG_PROTECT_FROM_CLOSE +,"\n"; print "flags was=$flags\n"; $flags |= HANDLE_FLAG_INHERIT|HANDLE_FLAG_PROTECT_FROM_CLOSE; print "Trying for flags=$flags\n"; SetHandleInformation($os_handle, 0x2, 0x2) or die "Can't SetHandleInfo +rmation: $^E,\nstopped"; GetHandleInformation($os_handle, my $newflags); print "flags now=$newflags\n"; $ENV{myfd}=fileno($fh); my $proc; #Win32::Process::Create($proc, $ENV{COMSPEC},"/c print_to_3.pl",1,0, " +." ) # or die "Can't run: $^E\n"; system 'print_to_3.pl'; print $fh "This is to fd $ENV{myfd} from the parent\n";

    print_to_3.pl

    open OUT,">&=$ENV{myfd}" or die "cannot dup $ENV{myfd}: $!\n"; print "Opened FD $ENV{myfd}\n"; $x=print OUT "***\nHere is data to FD $ENV{myfd}\n***\n"; warn "print=$x ($!)\n";

      The flags are on the OsFHandle and yet you are trying to share the Unixish 'fd'. Try $ENV{myosh} = $os_handle; instead and then open an fd and fh for that in the spawned process (via OsFHandleOpen).

      That's how I've done this successfully before.

      - tye        

        That works. Adding $ENV{myosh} = $os_handle; to the caller (also removing SetHandleInformation, it isn't needed) and rewriting print_to_3.pl as
        use Win32API::File qw(OsFHandleOpen); OsFHandleOpen(\*OUT,$ENV{myosh},"w"); $x=print OUT "***\nHere is data to OsH $ENV{myosh}\n***\n"; warn "print=$x ($!)\n" unless $x;
        works... Alas the "real" code I am dealing with that "print_to_3.pl" replaces is Unix-y C code. I have already made it use STDERR instead of its own stream, which is working well enough- if there's an error message then the stream is no good anyway, and in the usual case it's easier to manipulate STDERR .

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1006551]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (8)
As of 2014-12-25 02:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (159 votes), past polls