X-Spam-Check-By: sourceware.org
Date: Thu, 11 May 2006 13:42:31 +0200
From: Karel Kulhavy <clock AT twibright DOT com>
To: Dave Korn <dave DOT korn AT artimi DOT com>
Cc: cygwin AT cygwin DOT com
Subject: Re: tcdrain
Message-ID: <20060511114231.GA15156@kestrel.barix.local>
References: <20060510130441 DOT GC8871 AT kestrel DOT barix DOT local> <005101c6744c$d195a6a0$a501a8c0 AT CAM DOT ARTIMI DOT COM>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <005101c6744c$d195a6a0$a501a8c0@CAM.ARTIMI.COM>
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
Precedence: bulk
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
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

On Wed, May 10, 2006 at 05:14:30PM +0100, Dave Korn wrote:
> On 10 May 2006 14:05, Karel Kulhavy wrote:
> 
> > 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?
> 
>   Nope, but I can confirm that this is really how Windows works.  Cygwin
> relies on the win32 FlushFileBuffers function; it doesn't contain a
> kernel-mode device driver to manipulate the serial port registers, so this is
> probably as close as we can get.
> 
> > 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.
> 
> Yep, it does.  BTW, the opengroup posix spec is more definitive than man
> pages, which are often system- and architecture-specific.
> 
> http://www.opengroup.org/onlinepubs/000095399/functions/tcdrain.html
> 
> However the meaning of "shall block until all output written to the object
> referred to by fildes is transmitted" doesn't seem very clear to me.  If "the

But "the object" should be the same object for tcdrain and setting the
speed. The problem for cygwin is that the drain works in a different
point of the data pipeline than the speed, which is what corrupted my
data.

What POSIX means is I think that if you call drain and then set speed,
the data don't get corrupted.

I don't care if cygwin is posix compliant or not - either write there
that's there's an exception in this case, or implement it if you think
it's easy. If you don't do this, people will unnecessary waste time
discovering that what they were promised is not true.

> object referred to" is "the serial port", then it's fair to say that the data
> has been sent to the serial port; it says nothing about where and/or when the
> serial port sends it on to.  I can't see "the object referred to by fildes" as
> meaning the device attached to the cable on the far side of the serial port,
> so arguably it's unspecified what it should do about the on-chip buffers.
> IIRC tcdrain was only implemented a little while ago, and there was some
> discussion of the matter on the list, resulting in the current design
> compromise.
> 
>   Hmm.  It looks like it might be possible to call GetCommProperties and test
> dwCurrentTxQueue to see if it was zero, but I dunno if that'll work properly
> in all cases.  The docs for PurgeComm suggest using FlushFileBuffers, which is
> what cygwin does do, and don't suggest any issues in relation to caches.
> Maybe calling WaitCommEvent (..., EV_TXEMPTY, ...) might do what you want.  If
> you could do some experimentation and tell us what works, we might even be
> able to improve cygwin's tcdrain functionality.

I calculated a delay for 64-byte buffer (4xmore than typical 16550A/
Winbond que) and put it there and now it works.

CL<
> 
>   At the very worst, you could just look up the
> GetCommProperties->COMMPROP->dwMaxTxQueue and simply delay for that many
> character times (modulo current baudrate settings and flow control issues)
> before changing the speed.
> 
>     cheers,
>       DaveK
> -- 
> Can't think of a witty .sigline today....
> 
> 
> --
> 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/

--
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/