[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090727222010.1a5efb7b@lxorguk.ukuu.org.uk>
Date: Mon, 27 Jul 2009 22:20:10 +0100
From: Alan Cox <alan@...rguk.ukuu.org.uk>
To: OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Rafael J. Wysocki" <rjw@...k.pl>, Ray Lee <ray-lk@...rabbit.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] kdesu broken
> > My T60p lenovo laptop. If you can send me a debug prink patch i can redo the
> > test with the patches. I don't know what data i should start collecting so
> > that it make sense. This is the patch i tried
>
> If I read that part of emacs correctly, it seems to be assuming the data
> was already sent to master side if the child process was exited.
Oops.. that would be rather buggy.
It is true that the data has left the slave. It is not neccessarily true
the data has arrived on the master before the call to close() completes.
We can fake that but what the hell are the semantics if the process on
the master blocks or if both processes each end fill the queue and then
close so no data can be consumed.
> And if it's right, unfortunately, I guess we can't return -EAGAIN in
> this case to preserve behavior.
To avoid the EAGAIN the close needs to block until all queued I/O has
been processed by the ldisc the other end. That's not standards
guaranteed or even what happens with a non pty port, but it is doable
unless you take signals - we can't block signals or it can all deadlock.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists