Sergey Bugaev

Hi! So far, we use some heuristics and additionally hardcode some types that should be treated as text: https://github.com/bugaevc/wl-clipboard/blob/2c3cee1c8173d75b1411997b2c0f3e486194ac0c/src/util/string.c#L34-L51 Would it be not enough to just add CSV to the...

> I was initially planning to just add the CSV check, but I'm worried about the cat and mouse game of keeping up with unusual file types. Yeah I don't...

Hangs how? Can you check what it's waiting for?

> The usual approach for this would be to run things in different threads and then integrate them with each other via channels. That's an unfortunate workaround you'd have to...

> It's one of the many building blocks needed for building runtime-agnostic futures APIs. > Also I believe in the future no library crates should depend on async-std or tokio...

> Exporting fd seems tricky to-do in cross-platform way. It would work with proper epoll, but what about wepoll? I have very little idea about Windows internals, sadly :slightly_frowning_face: If...

> In the end, it’s not sufficient to export a single fd which the other runtime can monitor (in either runtime enviroment), as you’d need to share all fd’s that...

...which is what I've been asking for in the first place 😀

Sounds pretty cool — though it looks like the docs could use some improvements & more explanations. For example, [`park()` docs](https://docs.rs/async-io/0.1.2/async_io/parking/struct.Parker.html#method.park) say nothing about waiting for I/O, or about there...

> I wonder, is taking the epoll or kqueue fd actually useful? Note that the reactor keeps a mapping between event userdata (which is an u64 containing Source ID) and...