runtime: [API Proposal]: Use TimeSpan everywhere we use an int for seconds, milliseconds, and timeouts (Group 2+3)

Background and motivation

As discussed with @danmoseley this issue serves as a follow up for #14336 and is meant to represent the 2nd and 3rd group

API Proposal

Group 2

namespace System.IO {
    public abstract class Stream {
       public TimeSpan ReadTimeoutTimeSpan { get; set; }
       public TimeSpan WriteTimeoutTimeSpan { get; set; }
    }
}

namespace System.IO.Ports {
    public class SerialPort {
       public TimeSpan ReadTimeoutTimeSpan { get; set; }
       public TimeSpan WriteTimeoutTimeSpan { get; set; }
    }
}

namespace System.Media {
    public class SoundPlayer {
       public TimeSpan LoadTimeoutTimeSpan { get; set; } 
    }
}

namespace System.Net.NetworkInformation {
   public static class NetworkInformationTimeSpanExtensions {
       public static TimeSpan GetPacketReassemblyTimeout(this IPGlobalStatistics statistics);
       public static TimeSpan GetMaximumTransmissionTimeout(this TcpStatistics statistics);
       public static TimeSpan GetMinimumTransmissionTimeout(this TcpStatistics statistics);
   }
}

namespace System.Net.Sockets {
    public class Socket {
       public TimeSpan ReceiveTimeoutTimeSpan { get; set; }
       public TimeSpan ReceiveTimeoutTimeSpan { get; set; }
    }

    public class TcpClient {
       public TimeSpan ReceiveTimeoutTimeSpan { get; set; }
       public TimeSpan SendTimeoutTimeSpan { get; set; }
    }
}

namespace System.Timers {
    public class Timer {
       public TimeSpan IntervalTimeSpan { get; set; }
    }
}

Group 3

namespace System.Data {
    //  This would need to be a DIM.
    public interface IDbCommand {
       TimeSpan CommandTimeoutTimeSpan { get; set; }
    }

   public static class DataTimeSpanExtensions {
       public static TimeSpan GetConnectionTimeout(this IDbConnection connection);
   }

}

namespace System.Net.Sockets {
    public class LingerOption {
       public LingerOption(bool enable, TimeSpan time);
       public TimeSpan LingerTimeSpan { get; set; }
    }

    public class Socket {
       public void Close(TimeSpan timeout);
    }
}

Risks

This API does not conflict with other APIs, so I don’t see any risk here.

Edit: Changes to IDbCommand would break implementations (like SqlClient)

/cc @reflectronic /cc @briangru /cc @danmoseley /cc @bartonjs

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 1
  • Comments: 25 (22 by maintainers)

Most upvoted comments

I guess the last set is the winner. I can see the confusion though when you do ReceiveTimeoutTimeSpan and try to get ReceiveTimeout after that, there can be some truncation if we try to do the conversion. The doc would need clarify the behavior.

Question about some of the proposed APIs that are properties with setters. What happens if there’s a conflict?

For example:

var client = new TcpClient
{
    ReceiveTimeout = 5000,
    ReceiveTimeoutTimeSpan = TimeSpan.FromMinutes(10)
};

Which one wins?

Being outside runtime makes that possible. Unfortunately small team with a big backlog means that anything new will take time. See the area owner’s notes in https://github.com/dotnet/runtime/issues/51836#issuecomment-1012664600 for the basis of my information.

@danmoseley Should I outsource the SqlClient specific stuff to the SqlClient repo or will the API still be discussed in this repo?