Condition variables to reduce polling in crew

[wlandau]

nextget("cv") and mirai(.signal = TRUE) are incredibly useful. We have already discussed cv_value(nextget("cv")) as a constant-time way to count unresolved tasks (shikokuchuo/mirai#78 (reply in thread)). Development crew already does this.

Now, I am thinking of ways that nextget("cv") could reduce polling in both crew and targets. There is a ton of potential. The crux is where crew either:

• Waits until at least one task resolves, or
• Waits until all tasks resolve.

I would like to use something like until(nextget("cv")). It's simple in theory, but I find myself struggling:

1. until() decrements the cv. This is a challenge because crew thinks cv_value(nextget("cv")) is total cumulative number of resolved tasks. To use the cv correctly for Extended R dispatcher mirai#78 (reply in thread), I have to add back 1 if the cv was originally positive. And it's hard to tell if the cv was originally positive without hitting a race condition.
2. until() only sleeps if cv_value() is positive. I am not sure how to wait until all tasks resolve. It would be easier if the sleep could start at any value and simply wait for a change. If there were a way to wait until the cv climbs up to a user-defined fixed positive value, then this would be easier still.

[shikokuchuo]

Do you have a proposed syntax for the function you are looking for, some examples of how it would work?

As mentioned in #18 you may think it looks like a modified or more featureful version of until() but that makes it something else altogether.

[wlandau]

Yeah, on reflection I think this will work. In crew I can maintain a counter of resolved-but-not-popped tasks, and I can quickly sync the counter using something like while(until(cv, 0)) { self$count <- self$count + 1}, where cv gets forwarded signals from mirai::nextget(“cv”). Then wait() can decide whether to wait on cv using self$count (to make sure we avoid fruitlessly waiting on a zero-valued CV), and pop() can decrement the count by 1.

[shikokuchuo]

I think it works if you keep a counter of tasks as you launch them them. Then to wait for 'n' tasks, I was using something like this yesterday:

wait_n <- function(cv, n) {
    for (i in seq_len(n))
        repeat nanonext::until(cv, 1000L) && break
}

[wlandau]

Yup, that's definitely along the lines of what I am thinking. The only wrinkle is that I will need %->% because the pipe events are really going to come from mirai::nextget("cv"), but I don't want to risk decrementing mirai::nextget("cv") because crew relies on its cumulative properties. How do you feel about #23?

[shikokuchuo]

Well if it works it works I guess... but I'll need to do more testing to see how robust it really is. I think you can expect some sort of solution though, even if it turns out not to be %->%.

[shikokuchuo]

%~>% is now implemented, so hope you have enough for what you need!

[wlandau]

Thanks for merging #23! Super helpful! Feels great to get started with wlandau/crew#108.

As I get started, I am remembering #20 (reply in thread):

d606b6b allows constructing an interruptible

I am just now realizing how important user interrupts are here. Do you still have plans for that? On my end on Mac OS, it seems CTRL-C has no effect when I run until(cv, 10000) (using nanonext 1512036).

[wlandau]

I think I can work with that. until(msec = 500) seems kind enough to the CPU and responsive enough to CTRL-C. Please let me know if you think a different balance would be better.

[shikokuchuo]

I think it's fine to set it how you see fit. And just note that it's context-dependent. E.g. for wait_aio() the user will probably interrupt when it has been unresponsive for too long, so the interval I have actually set is 2000 msec as a little pause and return (after a long wait) doesn't seem to be noticeable. Something like 500 or 1000 I'd say are both sensible.

[shikokuchuo]

Actually the latest build 9009 now has proper implementations in C, with interruptible versions of call_aio, wait and until - call_aio_(), wait_() and until_() respectively. The response interval has been set to 400ms.

[wlandau]

Thanks, that's fantastic! Simplifies things on my end.

[wlandau]

Hmm... as it turns out, I actually need to manually wait in intervals anyway so crew can do its auto-scaling.