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.
| [reply] |
limit_output 1_000_000 monitored_process.exe
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] |
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] |