Re: How does one effect O_NONBLOCK?!

Edd <edd@xxxxxxxxxxxxxxxx> wrote:
Hi again Jens,

On Jun 2, 12:27 am, j...@xxxxxxxxxxx (Jens Thoms Toerring) wrote:
Edd <e...@xxxxxxxxxxxxxxxx> wrote:

Would pseudo-terminals help with this particular issue?

Yes, it would since using by a pseudo-terminal in between you
would get the child process to react exactly the same way as
it would if its stdout would be connected to a terminal (that's
why it's called a pseudo-terminal), i.e. it's stdout would be
line buffered (of course assuming that the application hasn't
changed the default buffering mode).

Ok great. Looks like I have some more reading to do, then!

;-)

But I'm curious, now; if using a pseudo-terminal allows you to create
a perfect proxy, what reason is there to use pipes? I guess larger
buffers make them more efficient for "noisy" programs?

Pipes are often used between a parent and a child process that
the parent spawned, but which didn't call exec(). So the author
wrote both the parents and the childs code and could avoid any
such issues. Then adding another layer of complexity completely
unneeded don't make sense. And it's not really a problem due
to the design of pipes as such, it's more a problem introduced
by the output buffering of the C standard output functions.
They may simply not flush the buffer to the pipe. And that's
where pseudo-terminals come to the rescue.

So normally things only get "interesting" if the childs exec()'s
a program that hasn't been written with the possiblilty of being
connected to a pipe in mind by using e.g. printf() and not flushing
the output buffer at the end of a line (or using setvbuf() etc) and
expects a kind of dialog with the user.

For the record, I will be using this function in a piece of software
used for automation of tasks. A bit like make in some ways. From the
sounds of things, pipes will probably suffice 99% of the time.
Occasionally though, I will want to capture and process child output
e.g. from pkg-config. I'm sure I won't need pseudo-terminals for pkg-
config either, but the system is scriptable, so I have to assume as
little as possible about the children that will be created.

I guess pkg-config shouldn't pose a problem since it doesn't seem
to do a "dialog" kind of thing (at least as far as I know) but just
outputs data and exits. And when it exits its buffers get flushed
automatically. So a simple pipe should be sufficient with that.

Regards, Jens
--
\ Jens Thoms Toerring ___ jt@xxxxxxxxxxx
\__________________________ http://toerring.de
.

Relevant Pages

  • Re: anonymous pipes
    ... You are probably better off using sockets unless you have some compelling reason to use pipes. ... redirecting input and output of the child process i have to use two ... parent say's "hello child" then child should respond "hello ...
    (microsoft.public.vc.mfc)
  • Re: anonymous pipes
    ... I have a parent-child set of processes that uses pipes to ... If the parent writes "hello child" it can wait for a response although ... redirecting input and output of the child process i have to use two ...
    (microsoft.public.vc.mfc)
  • Re: Newbie question on pipe() system call
    ... but nowhere I am mentioning the pid of which child process I ... it would be smart to use multiple pipes. ...
    (comp.unix.programmer)
  • Re: Program hanging when read()ing from pipe
    ... and I can read and write through the pipes. ... expect from the external program that is launched as child. ... I did some rewriting and the child process now ends normally (not ... background and has init as parent. ...
    (comp.unix.programmer)
  • Re: No libntp.so
    ... could simply set stdin/stdout to no buffering, but it appears for pipes ... You may want to read up on pipes, ptys and associated buffering. ... Why should we make ntpq draw ASCII ...
    (comp.protocols.time.ntp)