th1j5

Maybe worse: if I say the old and new graph come from different documents (see code) ``` const $rdf = require('rdflib'); const store = $rdf.graph(); $rdf.parse(old_graph, store, 'https://www.example.com/1', 'text/turtle'); $rdf.parse(new_graph,...

Hey, how is this issue going? Tokio is now version 1.2.0, so *maybe* it is stable enough to have a look at it again? I'm asking this because: I'm using...

Ok, then I'll just use something like `std::thread::spawn`. Not that it matters very badly... I do know that some crates use options in their Cargo.toml to mark what you want...

This (the message len of -EAGAIN) was the expected behaviour on a non-blocking flow. The question remains if an 'fqueue' event needs to be emitted for each keep-alive packet

Thus, keep-alive packets trigger an [`fevent`](https://ouroboros.rocks/cgit/ouroboros/tree/src/lib/dev.c#n1705) (with type `FLOW_PKT`) when they should not. I'm not sure if they should be filtered out in [`fqueue_filter`](https://ouroboros.rocks/cgit/ouroboros/tree/src/lib/dev.c#n1610) (they should not take [this if-statement](https://ouroboros.rocks/cgit/ouroboros/tree/src/lib/dev.c#n1632))...

No, the keepalives are indeed filtered out in fevent, but now the client cannot `dealloc` (no idea why, a bit late for me to figure it out tonight) see https://github.com/th1j5/ouroboros/tree/bug-fevent-keepalive...

This is what I get for the client when it's blocked, so it will have to do with a lock, I guess ```gdb (gdb) bt #0 futex_wait_cancelable (private=, expected=0, futex_word=0x7f6b3a311098)...

No, it seems it's not reliably reproduced, I just tested it and the different results were: 1) I reproduced the problem 2) It deallocated just fine 3) oping client stopped...

```bash $ ldd --version ldd (Ubuntu GLIBC 2.31-0ubuntu9.9) 2.31 ``` and yes, it only happened on the fevent fix, never encountered it on be

Forgot to answer, but your quick response is appreciated. Don't have anything else to add :)