Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #8319 > unrolled thread

What if a subprocess disconnects stdin and/or stdout?

Started byVictor Porton <porton@narod.ru>
First post2018-01-22 00:43 +0200
Last post2018-01-26 10:53 -0800
Articles 2 — 2 participants

Back to article view | Back to comp.programming


Contents

  What if a subprocess disconnects stdin and/or stdout? Victor Porton <porton@narod.ru> - 2018-01-22 00:43 +0200
    Re: What if a subprocess disconnects stdin and/or stdout? Ed Prochak <edprochak@gmail.com> - 2018-01-26 10:53 -0800

#8319 — What if a subprocess disconnects stdin and/or stdout?

FromVictor Porton <porton@narod.ru>
Date2018-01-22 00:43 +0200
SubjectWhat if a subprocess disconnects stdin and/or stdout?
Message-ID<p4353a$1is9$1@gioia.aioe.org>
I am writing "Command Communication Library":
https://github.com/vporton/libcomcom

The most immediate purpose is to (synchronously as of the planned first 
release):

Run an OS command with the given string written to stdin and with stdout 
returned (as a string) to the caller after the command finished.

It is clear what to do if the child process exits.

But what if the child process does NOT exit but closes stdin and/or stdout? 
What should I do in this case? Should I kill the process? Should I wait when 
it finishes? Should I return the stdout now, even despite the process has 
not yet finished?

P.S. This libcomcom is a VERY long time should be already have been written. 
I wonder if I am the first person who solves this problem.

-- 
Victor Porton - http://portonvictor.org

[toc] | [next] | [standalone]


#8338

FromEd Prochak <edprochak@gmail.com>
Date2018-01-26 10:53 -0800
Message-ID<85ccbac8-939d-4943-8229-d7e38861082c@googlegroups.com>
In reply to#8319
On Sunday, January 21, 2018 at 5:44:03 PM UTC-5, Victor Porton wrote:
> I am writing "Command Communication Library":
> https://github.com/vporton/libcomcom
> 
> The most immediate purpose is to (synchronously as of the planned first 
> release):
> 
> Run an OS command with the given string written to stdin and with stdout 
> returned (as a string) to the caller after the command finished.
> 
> It is clear what to do if the child process exits.
> 
> But what if the child process does NOT exit but closes stdin and/or stdout? 
> What should I do in this case? Should I kill the process? Should I wait when 
> it finishes? Should I return the stdout now, even despite the process has 
> not yet finished?
> 
> P.S. This libcomcom is a VERY long time should be already have been written. 
> I wonder if I am the first person who solves this problem.
> 
> -- 
> Victor Porton - http://portonvictor.org

What are your requirements? I see you defined the interface:
libcomcom_run_command()
Runs an OS command.

Parameters
input	passed to command stdin
input_len	the length of the string passed to stdin
output	at this location is stored the command's stdout (call free() after use)
output_len	at this location is stored the length of command's stdout
file	the command to run (PATH used)
argv	arguments for the command to run
envp	environment for the command to run (pass environ to duplicate our environment)
timeout	timeout in milliseconds, -1 means infinite timeout
Returns
0 on success and -1 on error (also sets errno).

But there is no description of the functionality other than
"Runs an OS command."

I think you need to fill in more of what is expected from this function.
There are only hints based on the parameters. For example, you asked:
> But what if the child process does NOT exit but closes stdin and/or stdout? 
> What should I do in this case? Should I kill the process? Should I wait when 
> it finishes? Should I return the stdout now, even despite the process has 
> not yet finished?

But it looks like you don't decide. The caller provides you with a
timeout parameter, even with a defined value for infinite wait.

There are features that are not defined like whether or not to kill
the subprocess when the timeout occurs. So you still have some work
to do in defining your requirements.

HTH,
  ed

[toc] | [prev] | [standalone]


Back to top | Article view | comp.programming


csiph-web