Runtime: [Ping] Consider adding synchronous path to Ping

[stephentoub]

The Ping class' synchronous methods are currently implemented as a blocking wrapper over its asynchronous implementation. A synchronous path could be put in place to avoid that, e.g. ala the code at http://referencesource.microsoft.com/#System/net/System/Net/NetworkInformation/ping.cs,eb2dfd41e9774d4a when async is false.

[tdinucci]

If there's still interest in this I'd be happy to take it

[karelz]

Thanks for your help! Assigned to you ...

[tdinucci]

Thanks @karelz

@stephentoub, there are 3 ways I can approach this, can you please let me know your preference?

• Focus on performance - here I wouldn't touch the async code so as not to introduce any overhead. Obviously the downside is that there's going to be a lot of duplication.

• Focus on maintainability (while obviously still keeping performance in mind) - here I would do a bit of refactoring so that both sync and async flows would share appropriate code in a clean way. This would mean pulling shareable code out into new methods so introducing a certain level of performance overhead.

• Try and walk a line between both - here rather than pulling code out into shared methods I'd do something like what the reference source does, i.e. handle both sync and async concerns within the same methods. Downside is obviously the result will be ugly and you're not getting the best of either world. I guess it could be argued that this may lead to even less maintainable code than having completely separate flows due to reduced readability.

[stephentoub]

My preference would be (2) then (3) then (1). Given the nature of the operation, I would be a bit surprised if there were meaningful differences between the various approaches, and thus would prefer to err on the side of maintainability.

[wfurt]

closed by dotnet/corefx#30000