A problem here is that the latency of the timer interrupt will affect the timing when you start your timer.

And the signal quality of your 100Hz will affect where in the cycle that the timer will capture the value.

Another alternative is to perform many capture events and average the result. The problem with that is that it will reduce the problem with jitter from latency and the capture signal, but will not solve the measurement error you get from either always starting the timer a bit late because of latency, or always capturing the timer value a little early or late depending on amount of noise and where in the curve form your input signal toggles.

Maybe you would be better off using a gated timer?

Another thing is that if you switch to a free-running timer, you would suffer from jitter but the average would always be correct to within the tolerance of the crystal and the resolution of the timer. With a free-running timer and just a pin interrupt, the average after 10 periods (remember to ignore the first period since it may not have started on a full period) would be very good and still produce a result after 100ms. And as long as you have some debounce logic for the pin interrupt, i.e. not allowing a new interrupt within some interval after the previous interrupt, and averages enough periods, you wouldn't be too hurt by noise on the input signal, or by the interrupt not happening on a well-defined position in the signal period.

Best is to use a processor with a more advanced timer, that can capture both the low-to-high and the high-to-low events without every stopping the timer. I'm not sure about the availability of more advanced timers for 8051 chips.