Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/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
Message-ID: <3FA62686.5080905@lynx-technik.com>
Date: Mon, 03 Nov 2003 10:57:26 +0100
From: "H. Henning Schmidt" <Henning DOT Schmidt AT lynx-technik DOT com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: RE: tcflush hang problem
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

I am pretty certain the the problem which is discussed in this thread 
has already been reported in
http://sources.redhat.com/ml/cygwin/2003-03/msg01529.html

There is obviously an input buffer, which overflows if you keep an open 
filedesc. on a serial port and let some external system generate input 
data on that port while your own app does not read them away from there 
fast enough. The message referenced above (from March 2003) also 
contains a reliable way to reproduce this problem. My guess is, that the 
tcflush() itself is probably not guilty in any way, it just helps 
reproducing the problem.

;Henning



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