Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
* Fix help, async_complete * More TODO cleanup * Fix imported types test, more complete README * Move readme todos to issues * Commit including hardcoded dep paths so I can copy them later if needed * Point to branch * Add `List` to map FfiConverter * Use `main` `metadata_no_deps` * Consume main uniffi w/ extra info on RustBuffer * Test runner action * Don't use sccache * Try "forcing" GC to see if it's JVM state * Try without coverage in parallel * Back to original CI, focusing on theorizing a fix * Try a longer delay before cancelling What if the logic is fine but the Java FFI is slow, so the delay finishes before the call from Rust gets back for it to await the abortable? * More exaggerated * Isolate failing test, add timing info * Don't isolate, remove GC * What if we don't block on initial call and wait longer than the times we're seeing in CI on the delay. The free is still being called, so nothing looks like it's leaking, but it is way slower than expected vs local (or even passing CI runs, which were faster than local) * The free was close in behind the delay finishing Try extending the delay a bunch * Try it in the real test * Add logging to main test * :/ * Maybe even longer? The free was half a ms after * Check when free happens in CI failure * Sanity check free timing on failures Right now when it works in CI the free happens ~1.3ms after the call to the delay trait (which makes sense given the 1ms delay in Rust before it aborts). When it doesn't work though the free doesn't happen until ~.6ms after the delay call fully finishes, so 100.5ms after the call to the delay trait. It seems like a bug where the FreeImpl isn't being called from Rust in time, but I want to see if bumping the delay to 200ms results in 1.3/200.5, or 1.3/100.5 still * Log in millis to compare to rust * Busy wait when polling CompletableFuture callback We can't trust Java's `CompletableFuture` to wake a suspended thread correctly when the `CompletableFuture` being blocked on is `complete()`, so we're manually busy waiting the futures thread for now. * Handle CI issue still present * Try to get some more info about what handle is left * Push the timing up a bit * Add changelog and initial releasing doc. * Drop extra logging * More permissive timing to avoid intermittent failure
- Loading branch information
