On Fri, Feb 3, 2023 at 12:38 PM 'Lucas Christian' via golang-nuts
<golang-nuts@googlegroups.com> wrote:
>
> Apologies for reviving an old thread, but thought this might be the most
> efficient way to keep context.
>
> I'm looking at a similar issue Thomas encountered, but in this case I'm
> concerned about how to handle errors returned from StdoutPipe()/StderrPipe()
> and properly clean up after that. e.g.:
>
> cmd := exec.Command(myCommand, myArgs...)
>
> stdout, err := cmd.StdoutPipe()
> if err != nil {
> // log warning or bail out
> }
>
> stderr, err := cmd.StderrPipe()
> if err != nil {
> // log warning, if we bail out we will leak the os.Pipe allocated
> internally in cmd.StdoutPipe()
> }
>
> err = cmd.Start() // if this fails, it *will* clean up both pipes
>
> Looking at the source, both StdoutPipe() and StderrPipe() allocate os.Pipe()s
> internally. Since these methods return the reader I can technically close
> that one myself but the writer side of the pipe will presumably leak if
> cmd.Start() is never called. In my usecase it's probably an acceptable
> compromise to just complain to the log and move along with starting the
> process, but if my understanding is correct it feels like an omission in the
> language spec that there is seemingly no way to clean up a the pipes
> associated with a command that is never started.
As a practical matter I wouldn't worry about it, as StdoutPipe and
StderrPipe should approximately never fail. I think that the only way
they could fail would be if you hit the limit on the total number of
open file descriptors.
If they do manage to fail, it's a fair point that there is no
supported way to close any earlier pipes. Again it's unlikely to be a
practical problem as any lingering file descriptors will get closed by
the finalizer associated with each file descriptor. But, yes, it
looks like a bit of a hole in the API.
Ian
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXHEHOeiVkb22uoKOyLNWN9EfTkXkcA5T51DuHV8z%3DCzQ%40mail.gmail.com.
