Introduce a clock type field onto gpr_timespec.
Use it to validate that arithmetic on time types makes even some vague
kind of sense.
diff --git a/src/ruby/ext/grpc/rb_completion_queue.c b/src/ruby/ext/grpc/rb_completion_queue.c
index 2d52d96..8a98e16 100644
--- a/src/ruby/ext/grpc/rb_completion_queue.c
+++ b/src/ruby/ext/grpc/rb_completion_queue.c
@@ -82,7 +82,7 @@
next_call.cq = cq;
next_call.event.type = GRPC_QUEUE_TIMEOUT;
/* TODO: the timeout should be a module level constant that defaults
- * to gpr_inf_future.
+ * to gpr_inf_future(GPR_CLOCK_REALTIME).
*
* - at the moment this does not work, it stalls. Using a small timeout like
* this one works, and leads to fast test run times; a longer timeout was
@@ -143,7 +143,7 @@
TypedData_Get_Struct(self, grpc_completion_queue,
&grpc_rb_completion_queue_data_type, next_call.cq);
if (TYPE(timeout) == T_NIL) {
- next_call.timeout = gpr_inf_future;
+ next_call.timeout = gpr_inf_future(GPR_CLOCK_REALTIME);
} else {
next_call.timeout = grpc_rb_time_timeval(timeout, /* absolute time*/ 0);
}
diff --git a/src/ruby/ext/grpc/rb_grpc.c b/src/ruby/ext/grpc/rb_grpc.c
index 699548b..706a2a7 100644
--- a/src/ruby/ext/grpc/rb_grpc.c
+++ b/src/ruby/ext/grpc/rb_grpc.c
@@ -235,11 +235,11 @@
rb_define_const(
grpc_rb_mTimeConsts, "INFINITE_FUTURE",
TypedData_Wrap_Struct(grpc_rb_cTimeVal, &grpc_rb_timespec_data_type,
- (void *)&gpr_inf_future));
+ (void *)&gpr_inf_future(GPR_CLOCK_REALTIME)));
rb_define_const(
grpc_rb_mTimeConsts, "INFINITE_PAST",
TypedData_Wrap_Struct(grpc_rb_cTimeVal, &grpc_rb_timespec_data_type,
- (void *)&gpr_inf_past));
+ (void *)&gpr_inf_past(GPR_CLOCK_REALTIME)));
rb_define_method(grpc_rb_cTimeVal, "to_time", grpc_rb_time_val_to_time, 0);
rb_define_method(grpc_rb_cTimeVal, "inspect", grpc_rb_time_val_inspect, 0);
rb_define_method(grpc_rb_cTimeVal, "to_s", grpc_rb_time_val_to_s, 0);