X-Spam-Check-By:	sourceware.org
Date:	Wed, 10 May 2006 15:04:41 +0200
From:	Karel Kulhavy <clock AT twibright DOT com>
To:	cygwin AT cygwin DOT com
Subject:	tcdrain
Message-ID:	<20060510130441.GC8871@kestrel.barix.local>
Mime-Version:	1.0
X-Orientation:	Gay
X-Stance:	Goofy
User-Agent:	Mutt/1.5.11
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Hello

It looks like tcdrain in cygwin doesn't wait until data are transmitted,
but just drains the software buffer, and doesn't drain the buffer in the
16550A chip. Can you please confirm that this is really how Cygwin
works?

I got data corrupted because of this because the data rate was switched
before all the old data got transmitted.

If it's this case, I suggest to add a note about this exception into
http://www.cygwin.com/cygwin-api/std-posix.html

Doesn't POSIX say "tcdrain()  waits  until all output written to the
object referred to by fd has been transmitted" (taken from man tcdrain),
in which case the aforementioned behaviour would not be POSIX compliant.

CL<

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

- Raw text -