On Fri, 2008-10-24 at 13:20 -0400, Carolyn Beeton wrote:
> > 2. The comment on getOutput isn't so clear. Perhaps this is an
> > improvement:
> >
> > /// Wait until the process produces output on stdout or
> > stderr, or /// exits. Returns -1 if process exits. If
> > output is obtained, /// sets 'message' to the output and 'fd'
> > to STDOUT_FILENO or STDERR_FILENO /// depending on which fd
> > output was obtained from, then returns >0.
> > /// 'message' values may be broken at arbitrary points.
> > virtual int getOutput(int& fd, UtlString& message) = 0;
>
> I am thinking of changing it to a "push" method instead of requiring the
> application to "pull" the messages. So the app would call
> OsProcess::setCaptureOutput(OsCallback handleStdoutMessage, OsCallback
> handleStderrMsg)
> once before launch. The wait function would then call select in a loop
> if the callbacks were set, and invoke them to pass the message to the
> app.
>
> OR
>
> another option (since Scott didn't like the first getOutput) would be to
> return two strings, rather than the fd (which is a bit weird, I'll
> admin). So it would look like
> int getOutput(UtlString& stdoutMsg, UtlString& stderrMsg)
> and you could get one or the other, or both, but getting neither would
> indicate the child process was gone.
>
> Any preference?
The second form seems easier to me.
I think that the process being gone (or not) should be in the return
status, not a side effect of the state of the variables.
I'd also pass the variables at UtlString* - that allows the caller to
indicate that they don't care about one or the other by just passing a
NULL for that one. So:
getOutput(NULL, &stderrStr)
would get back any stderr output, but would throw away any stdout.
> > 4. The placement of the null is incorrect here:
> >
> > + // read until all input has been read
> > + rc = read(realFd, buf, sizeof(buf)-1);
> > + buf[sizeof(buf)-1]=0;
> >
> > as it will be incorrect if rc < sizeof(buf)-1.
> >
> > 5. But I think we can omit placing a null at all using code like:
> >
> > printf("read %d bytes more: %.*s\n", rc, rc, buf);
> >
> > message.append(buf, rc);
>
> I'll try again, but I don't think it works without adding the nulls
> because if we return from the read with a full buffer, it won't be
> null-terminated and then append doesn't do the right thing. I test with
> the buffer size set very low so I can see what it does.
the form Dale suggests should work - a UtlString can have embedded null
bytes. That variable 'rc' should be renamed 'returnedBytes' or
something more descriptive.
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
