Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #8319 > unrolled thread
| Started by | Victor Porton <porton@narod.ru> |
|---|---|
| First post | 2018-01-22 00:43 +0200 |
| Last post | 2018-01-26 10:53 -0800 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.programming
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
| From | Victor Porton <porton@narod.ru> |
|---|---|
| Date | 2018-01-22 00:43 +0200 |
| Subject | What 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]
| From | Ed Prochak <edprochak@gmail.com> |
|---|---|
| Date | 2018-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