Date: Thu, 22 Jan 2009 10:55:22 -0500
From: Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Problem using select() with com0com virtual serial ports
Message-ID: <20090122155522.GA5369@ednor.casa.cgf.cx>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <7701e1400901220725r5712f806sff846b9aff8b4be3 AT mail DOT gmail DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7701e1400901220725r5712f806sff846b9aff8b4be3@mail.gmail.com>
User-Agent: Mutt/1.5.16 (2007-06-09)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Note-from-DJ: This may be spam

On Thu, Jan 22, 2009 at 10:25:32AM -0500, Paul Ingemi wrote:
>I'm using Cygwin with com0com, and I find that every other time I read
>a character from the virtual serial port, select() continues to
>believe the serial port is ready, but then read() will block until a
>character actually comes in. This does not happen with a real serial
>port.
>
>Attached below is a test program which exhibits the symptoms when used
>with com0com virtual serial ports.
>
>I worked around the problem by performing a second select()
>immediately after the first one returns with ready file descriptors.
>That second select determines which of these really are ready.
>
>Using strace and the source code for Cygwin, I worked with the author
>of com0com, Vyacheslav Frolov, to find a potential problem and
>solution. That thread is here:
>
>http://sourceforge.net/forum/forum.php?thread_id=2885701&forum_id=440108
>
>Vyacheslav suggests that initially peek_serial() returns because
>st.cbInQue is nonzero. However, since we didn't wait for a comm event,
>EV_RXCHAR is still set on the comm handle. The next time into
>select(), st.cbInQue is zero but WaitCommEvent succeeds immediately
>due to the previously set event.
>
>By clearing the comm event mask (and therefore the comm event) before
>setting it to EV_RXCHAR:
>
>select.cc function peek_serial():
>  ...
>  SetCommMask (h, 0);          // <=== added
>  SetCommMask (h, EV_RXCHAR);
>  ...

This seems like a hack to me.  I don't see anything in the MSDN
documentation which would imply that SetCommMask (h, 0) should cause
this type of behavior.  Wouldn't the fact that this works for a regular
serial driver imply that there is a problem with the com0com driver?

It is a simple enough hack that I don't mind adding it, if it fixes your
problem but I am not convinced that your driver is operating correctly.

cgf

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