in reply to Re^2: Windows-specific: Limiting output of created files
in thread Windows-specific: Limiting output of created files

The tee could attempt to kill the sender after the limit is reached,

The problem then is how tee finds out the pid of the producer process?

or simply refuse to copy to output.

It could, but then both processes might never end. Even if the producer process will eventually reach a natural end, it will take far longer, because of all the buffering and handshaking involved in the pipe.

if Windows tries "naive" error handling routines when you close the incoming handle.

If the producer application is just ignoring write failures, then there doesn't appear to be any 'naive error handling" involved. Indeed, the reason the cpu usage climbs after the pipe is severed, is because the producer application starts running much more quickly. As there is no buffering and handshaking involved, in the absence of any other limiting factors, its write loop just runs much more quickly than if the writes were succeeding.

The problem is it might never finish.

The nice thing about the piped-open overseer process is that it covers pretty much every eventuality. Save the possibility that the producer process stops writing, but doesn't close the pipe or terminate, before it reaches the limit specified in the overseer. Of course that can also be handled using a thread or can_read.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."
  • Comment on Re^3: Windows-specific: Limiting output of created files

Replies are listed 'Best First'.
Re^4: Windows-specific: Limiting output of created files
by ikegami (Patriarch) on Apr 03, 2009 at 17:42 UTC

    The problem then is how tee finds out the pid of the producer process?

    The monitor could use a syntax similar to strace. 

    limit_output 1_000_000 monitored_process.exe

    [download]

    Having launched the monitored process puts limit_output in a position to monitor and control it.

    Update: Ah shoot. I think you already mentioned this.

[reply]
[d/l]
[select]
Re^4: Windows-specific: Limiting output of created files
by rovf (Priest) on Apr 06, 2009 at 08:10 UTC
    The problem then is how tee finds out the pid of the producer process?

    Hmmm... I'm doing now IPC::Run::run to invoke the command. Is there an asynchronous way to do this with IPC::Run (similar to using spawn, so that my main process continues to run and then explicitly wait for the subprocess to finish? In this case, I see a possibility to pass the pid to my tee process. The problem seems to be that IPC::Run on Windows offers only part of the documented features.

    -- 
    Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]
[select]
      The problem seems to be that IPC::Run on Windows offers only part of the documented features.

      Then the question becomes:why continue to try and use a module that doesn't work on (on of) your target platforms?

      The last few times I looked at IPC::Run--2 or 3 years ago now--it used very complicated and iffy mechanisms (at least on Win32), to try and achieve stuff, that could be done much more simply with built-in features like the piped-open. And not very successfully from what I saw.

      If you are wedded to the use of that module, you'll need to talk to the author to look for fixes.

      If you are not, and if you can describe the limitations you are encountering with the suggestion I made in Re: Windows-specific: Limiting output of created files, then I could try to suggest work arounds or enhancements to address them.

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
        why continue to try and use a module that doesn't work on (on of) your target platforms?

        Simply because I didn't know of a better one ;-)

        Basically this is my wishlist:

        • Run an external command, where I have the command name and the arguments in an array, and get it's exitcode
        • No shell interpretation (globbing, quote handling) be done on the arguments
        • Being able to redirect stdout and stderr independently
        • Nice to have, but not strictly necessary: The same code should be used on Windows 2000 and Unix
        I must admit that my knowledge about process handling on Windows is limited. When I asked other Perl programmers with more experience in Windows, they recommended IPC::Run, despite its problems, but I am open to learn other alternatives.

        -- 
        Ronald Fischer <ynnor@mm.st>
[reply]
[d/l]

In Section Seekers of Perl Wisdom