Skip to content

Dont throw exception in SerialStream constructor if dtr or rts is not available#48577

Merged
krwq merged 3 commits intodotnet:mainfrom
sleeuwen:serialstream-virtualport-ctor-exception
May 5, 2021
Merged

Dont throw exception in SerialStream constructor if dtr or rts is not available#48577
krwq merged 3 commits intodotnet:mainfrom
sleeuwen:serialstream-virtualport-ctor-exception

Conversation

@sleeuwen
Copy link
Contributor

Dont throw IOException in SerialStream constructor when setting dtr and/or rts is not possible (for example virtual ports on Linux cannot set this and currently crash in the constructor of SerialStream making it impossible to use on those ports)

This fixes #31523 using the suggestion in #37841. This only fixes the Linux version, not the windows one, so I don't think it completely fixes #37841 (I could probably add the try/catch in the windows implementation as well if you want me to).

Dont throw IOException in SerialStream constructor when using a virtual port on
linux.
Setting DtrEnable or RtsEnable are not possible due to the termios commands not
implemented by socat sockets. This fix ensures no exception is thrown in the
constructor when we didn't even set the dtrEnable or rtsEnable parameters
explicitly and allows the usage of SerialStream with those virtual ports.
@ghost ghost added the area-System.IO label Feb 21, 2021
@dnfadmin
Copy link

dnfadmin commented Feb 21, 2021

CLA assistant check
All CLA requirements met.

Base automatically changed from master to main March 1, 2021 09:08
@carlossanlop carlossanlop requested review from krwq and wfurt March 4, 2021 18:22
{
DtrEnable = dtrEnable;
}
catch (IOException)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making the change, @sleeuwen . This fix is on pair with @krwq suggestion in the issue to catch the exception.
@krwq @wfurt is it possible to unit test these changes?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This constructor is internal. It might be a good idea to document the new behavior in the APIs that consume it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wondering if we should swallow the exception only when dtrEnable=false. I see no reason to fail in that case. However when somebody as asking for DTR I'm not sure if it is ok to silently ignore the request.

As far as the testing @carlossanlop : we currently do not have permanent setup with serial hardware and this is also HW specific e.g. difficult to test in general environment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@carlossanlop I'm not sure I understand what you're asking with documenting the new behavior. There is only one consumer as far as I can see, and that is the SerialPort in it's Open() method.

@wfurt I'm fine with only swallowing the exception if dtrEnable=false, but before I do I'd like confirmation that's what needs to be done.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wfurt Can you confirm that we should only swallow the exception when dtrEnable=false?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @wfurt swallowing an exception is only acceptable when dtrEnable=false and similarly for rts. Even better solution could be to try to see what native call returns and avoid throwing/catching completely

@sleeuwen
Copy link
Contributor Author

I've updated the PR to only swallow the exception when the value it's trying to set is false.

Copy link
Member

@krwq krwq left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me as it's better than it was before. I'd prefer we didn't throw and catch but that can be improved in the future.

Thanks for the contribution!

@IFoundTheLight
Copy link

Is it possible to get this commit into a build sooner than November?

@LeonidFirdman
Copy link

Is it possible to fix the same issue when using a virtual port on Windows?

@krwq
Copy link
Member

krwq commented Jun 28, 2021

@IFoundTheLight I think that nuget package might already be available: https://www.nuget.org/packages/System.IO.Ports/6.0.0-preview.5.21301.5

@LeonidFirdman possibly yes - note that we are currently not investing in this area so we will be relying solely on contributions...

@LeonidFirdman
Copy link

@krwq Currently, this issue affects all new Intel platforms because starting from the SkyLake in Core-i platforms and the ApolloLake in the Atom platforms, the Serial IO UART interface is implemented with TX, RX, CTS, RTS signals only.

@krwq
Copy link
Member

krwq commented Jun 30, 2021

@LeonidFirdman I'd recommend to start with creating a new Windows specific issue and provide link to this PR and all info like the one you shared above

@ghost ghost locked as resolved and limited conversation to collaborators Jul 30, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Unconditionally setting Dtr in SerialPort Open fails in some devices that doesn't support Dtr SerialPort error on Virtual Serial Port for USB LINUX

9 participants