Re: Problem using select() with com0com virtual serial ports

[Paul Ingemi <pingemi@gmail.com>]

On Sat, 24 Jan 2009 16:26:39 -0500 Christopher Faylor wrote:
>On Sat, Jan 24, 2009 at 03:30:34PM -0500, Paul Ingemi wrote:
>>* On Fri, 23 Jan 2009 11:17:57 +0100 Spiro Trikaliotis wrote:
>>>* On Thu, Jan 22, 2009 at 10:55:22AM -0500 Christopher Faylor wrote:
>>>> On Thu, Jan 22, 2009 at 10:25:32AM -0500, Paul Ingemi wrote:
>>>[...]
>>>> 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.
>>>>
>>>> As I had added serial port access to the Windows version of VICE one or
>>>> two months ago, I can tell that the com0com driver is indeed buggy.
>>>>
>>> IMHO, the better solution is to fix com0com, and not to apply some
>>> hotfixes to other software (cygwin, VICE, whatever). That's the approach
>>> I followed, too, ignoring com0com completely. If I might have some time,
>>> I might want to debug com0com myself, but don't hold your breath on it.
>>
>>I agree and adding a hack to cygwin isn't necessary due to the
>>existance of a workaround. That said, I think it's premature to blame
>>com0com without finding the root cause of the problem.
>>
>>Over the past two days I've been attempting to create an -mno-cygwin
>>executable that can reproduce the behavior I'm seeing under Cygwin.
>>Thus far I haven't successfully reproduced this behavior outside of a
>>Cygwin environment despite copying most of the code for how Cygwin
>>performs select() and read().
>
>I don't really see why it is necessary to stand you your head here.

I'm not sure I understand what you mean by "stand you your head"... if
you're asking why I'm going through this effort to reproduce the issue
outside of Cygwin, it's mainly because I can't easily debug the kernel
driver so I'm doing as much as I can in userland.

Creating a minimal reproduction gives me more information about the
problem. For instance, because copying most of the select() and read()
code out of Cygwin into a stand-alone executable didn't reproduce the
issue, I know there's another contributing factor that I have not
copied.

>Your change added a function call which, as far as I can tell from
>documentation, should be a no-op.

Agreed, although this only tells us the documentation presents a leaky
abstraction over what SetCommMask actually does.

>The change is not required for normal serial operation.  To me, that
> shows pretty clearly that com0com is doing something nonstandard.

It shows that com0com doesn't behave identically to Windows' serial port driver.

If I were to tell that to the com0com folks, they would point out
their driver works with other Windows applications, so Cygwin must be
nonstandard. In reality, Cygwin isn't necessarily doing something
nonstandard. It just doesn't behave identically to most Windows
applications.

For my purposes, I can use two select()s to work around the problem.
In the meantime, I'm doing my best to find the cause in what free time
I have. I hope that clears up any misunderstandings.

-- 
Paul Ingemi

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