Kaleb Barrett

So I can't guarantee this is the way it is, but it seems that this is the way it was intended to be. Four states: * GPI_FREE: no callback registered....

The obvious issue is that `cleanup_callback` is used for several functions and called from multiple locations. I think the easiest solution is to create a `disarm_callback`, which is intended to...

A follow on deletes `GPI_CALL`, because it's completely useless. Running the callback should put it in the `GPI_DELETE` state so it's always cleaned up if not re-enabled.

This is what I got so far: ```c++ int GpiCommonCbHdl::run_callback() { switch (get_call_state()) { case GPI_PRIMED: { set_call_state(GPI_DELETE); this->gpi_function(m_cb_data); return 0; } case GPI_DELETE: { // callback was disarmed, but...

I'm actually thinking that `arm_callback` should return a handle and `disarm_callback` should take a handle. This is to support multiple callbacks. And of course `set_user_data` on the callback should be...

@imphil the failure seems random. It's been hit or miss, mostly miss, since we reintroduced it.

Does `First` not work for you? `with_timeout` is just a convenience wrapper around `First`.

Sounds appropriate to me, feel free to provide a PR.

I don't think it really should matter since we already wait until the read write stage to apply writes. It does, however, make `setimmediatevalue` function weirdly. I don't really understand...

> I thought `value` was the "non-blocking" assignment and `setimmediatevalue` was the "blocking" one. This was the intent AFAICT. > But with `vpiInertialDelay` there doesn't appear to truly be a...