Re: Getting last data from child process in Leopard
Re: Getting last data from child process in Leopard
- Subject: Re: Getting last data from child process in Leopard
- From: Ingemar Ragnemalm <email@hidden>
- Date: Thu, 27 Mar 2008 15:32:48 +0100
Steve Checkoway wrote:
With a pty, it shouldn't buffer the pipe to a deadlock. That's the
point. But maybe that is the problem, that pty's in Leopard buffer
data when Tiger does not.
Could be, I don't still have Tiger around to try. Then again, both
Leopard and the version of Linux I was using before both buffer the
printf() if I remove the fflush(). The difference is that Linux
reports child quit, then it reads 16 bytes "hello!there!BYE!" whereas
Leopard loses the data. This must be the loss you were describing.
Maybe that is a bug, I'm not in a position to say. Jordan or Terry
know far more than I.
Exactly. Depending on buffering, the data may be early or late, but it
should not just disappear. With too much buffering (which is what I get
if I use pipes instead of ptys) the last data arrives in a big chunk at
the end, but it does arrive at all.
As a side note, this runs on (at least this particular flavor of)
Linux as well with the small changes (included in the file) to
include <pty.h> instead of <util.h> and to break out of the loop
when read() returns -1 and errno is EIO.
It is all built from common Unix calls so it should work. Didn't
link in RHEL though, and that's the only Linux I have easily
accessible.
I don't have red hat, but it worked for me on both ubuntu (ppc) and
fedora (x86). Did you remember to pass -lutil to gcc?
You are right, I just missed -lutil. And it seems to work just fine,
which means that RHEL seems to behave like Tiger.
You're still using buffered IO in the signal handler. You simply
cannot do that. Read the sigaction(2) man page.
Well, I have had no problems with that, but that doesn't matter, it
doesn't affect the real problem. I can do the whole thing without signals.
So, Leopard is losing data when at least Tiger does not, and RHEL also
seems to work. Under Leopard, you randomly lose data, sometimes it works
but all too often it doesn't.
I have found one solution that might do the trick. I spawn a pthread and
let it sit and do blocking read()s, and whenever it gets something, it
copies it over to a buffer that the main thread can poll. This solution
needs some kind of semaphores when accessing common data, of course, but
that can be done. I am testing this approach right now and it looks very
promising No lost data at all so far.
Another solution would be to make a pipe to a process that does these
blocking read()s, and fflush() everything to the main program to get a
smooth data flow.
That is my conclusion so far. Thanks for the feedback! It is much
appriciated!
/Ingemar
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden