Configurable sleeps

[zmitchell]

Hi, I was integrating rexpect into a project and found that the sleeps are longer than what we needed. Specifically the sleep in read_until is 100ms, and I found that decreasing this to 5ms sped up some of our tests that are using rexpect.

rexpect/src/reader.rs

Line 287 in be7f1ab

thread::sleep(time::Duration::from_millis(100));

Of course I wouldn't suggest everyone using 5ms, so maybe there's room for configurability? For now I have a fork with that small change.

[epage]

We already have a timeout, this is just the sleep to yield the thread within that timeout. We should probably make the sleep dependent on the timeout so we don't sleep longer than it.

I'm open to ideas of how we should calculate the sleep.

[zmitchell]

If I understand correctly this are two different times though in the sense that if I receive the output I'm looking for 1ms after the first run of the loop I need to wait 100ms to find out, and I incur that 100ms for each back and forth with the shell. This adds up pretty quickly in a test scenario where an rexpect-using test can take multiples of 100ms whereas other tests may take 10ms. That's more my concern.

[epage]

So if I'm understanding correctly, you don't want to change the timeout, just how long until the process wakes up for it to check if its done, making this closer to a busy loop?

[zmitchell]

Yes, but I want to be able to make that choice for myself. I think there are totally valid reasons that not everyone would want something closer to a busy loop.

[epage]

Seems reasonable. Thanks for taking the time to clarify the request!

[peterman42]

Hey team, about this issue, does @zmitchell work on it, or could I jump-in and work on it from my side?