antoyo/futures-glib-rs

futures-glib-rs's Issues

Recursive event loop

@alexcrichton
Hi, I found out that nested event loop does not actually work with futures-glib.

So, here's what I tried:
I made the source recursive:

source.set_can_recurse(true);

so that the dispatch function can be called recursively.

The problem is that a BorrowMut error will show up because the dispatch function will be called before the end of the call to poll_future_notify so that the task is still borrowed when trying to borrow it again in the recursive call.

Do you have an idea on how I could allow the nested event loop?
In other words, is there a way to poll a future while this specific future is currently being pulled? (edit: Oh, I think it does not make sense: even if I was able to do that, I'll end up with two mutable references which is not sound)

I can show you a code that triggers this issue, but it is not a simple example, it is in my relm crate, so it's not easy to figure out what happens.

Thanks for your help.

**Edit: ** As far as I understand, it is not correct to support recursive event loop. Am I right?

Cannot build on windows

Hi there :)

Building on windows https://github.com/antoyo/relm/blob/master/examples/clock.rs fails with following error:

Compiling futures-glib v0.3.1
error[E0423]: expected value, found module `ptr`
  --> C:\Users\p\.cargo\registry\src\github.com-1ecc6299db9ec823\futures-glib-0.3.1\src\io\mod.rs:41:18
   |
41 |         assert!(!ptr.is_null());
   |                  ^^^----------
   |                  |
   |                  did you mean `ptr::is_null(...)`?

error[E0423]: expected value, found module `ptr`
  --> C:\Users\p\.cargo\registry\src\github.com-1ecc6299db9ec823\futures-glib-0.3.1\src\io\mod.rs:43:20
   |
43 |             inner: ptr,
   |                    ^^^ not a value

error: aborting due to 2 previous errors

error: Could not compile `futures-glib`.
warning: build failed, waiting for other jobs to finish...
error: build failed

Building the same on linux works fine

Poll the tokio event loop

Hello @alexcrichton.
I made some experiments with an alternative approach: polling the tokio event loop instead of trying to integrate all the FDs into glib event loop.

You can see how it allows us to use tokio networking code directly, instead of having to reimplement everything for futures-glib, in this test:
https://github.com/antoyo/futures-glib-rs/blob/feature/poll-epoll/tests/tcp.rs

What do you think of that approach?
Do you see any downsides to this approach?
I think we can also poll kqueue, but I'm not sure about IOCP.

I made some changes a in fork of tokio-core to be able to get the event loop fd.

Thanks for your help.

invalid index

My hyper example can fail with the following:

thread 'main' panicked at 'invalid index', /checkout/src/libcore/option.rs:794
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: core::option::expect_failed
             at /checkout/src/libcore/option.rs:794
   1: <core::option::Option<T>>::expect
             at /checkout/src/libcore/option.rs:297
   2: <slab::Slab<T, I> as core::ops::IndexMut<I>>::index_mut
             at /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/slab-0.3.0/src/lib.rs:283
   3: <futures_glib::future::Inner as futures_glib::SourceFuncs>::dispatch
             at /home/user/.cargo/git/checkouts/futures-glib-rs-522395b3625f7353/b780e29/src/future.rs:106
   4: futures_glib::dispatch
             at /home/user/.cargo/git/checkouts/futures-glib-rs-522395b3625f7353/b780e29/src/lib.rs:733
   5: g_main_context_dispatch
   6: <unknown>
   7: g_main_loop_run
   8: futures_glib::MainLoop::run
             at /home/user/.cargo/git/checkouts/futures-glib-rs-522395b3625f7353/b780e29/src/lib.rs:295
   9: client::main

The line is:

                let slot = &mut queue[index];

Futures impl allows moving non-Send data to another thread / allows unsafe usage of stack references

Currently it's possible to create a future (e.g. Timeout) and run it on the GLib main loop, and then use combinators like and_then to add a closure. As the GLib main loop could run in a different thread, this would allow sending non-Send data from one thread to another.

Similarly it seems like there is no 'static here, which brings you another set of unsafeties. You could place a reference to the stack into your closure, and there is no guarantee that the closure is called before your current stack frame disappears (e.g. the current function returns).

Fix AppVeyor

It looks like AppVeyor is using an old Rust version, which makes the tests fail.