On 25-06-18 20:05, Russel Winder wrote:

This way of working relies on having a ready made futures, executors, and channels system with a single threaded task pool system. D doesn't seem to have one, though I am sure std.parallelism and vibe.d both have what is needed within them. Of course Rust has Tokio (equivalent of vibe.d) and Rayon (equivalent of std.parallelism). Tokio appears based on Rust futures, but Rayon appears not to use them. I can sort of understand this, Tokio is I/O bound and so can use the I/O bound futures, whereas Rayon needs something much more lightweight with better work-stealing.

I am not sure making GtkD rely on vibe.d is the right thing to do, and I am not sure the vibe.d people would be up for pulling out their futures stuff as a separate dependency. Creating something just for GtkD doesn't seem cost effective.

I suspect I'll just go with glib.Timeout as a way of mocking up something analogous. I think Timeout rather than Idle, as it should use less CPU resources.

Writing a vibe.d based GSource, that would live in a small separate
library might be an option, but it wouldn't be as integrated as the Rust
version.

A async library that is part of the standard library would be the best
option, also giving some consistency between libraries from different
projects. Photon (https://github.com/DmitryOlshansky/photon) also looks
promising.