-
-
Notifications
You must be signed in to change notification settings - Fork 119
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add convenience futures API #31
Comments
I'll make use of these in my application to see how they go. Let me now if they evolve, so I can update. |
@russel You'll get all updates if you subscribe to this issue :) Also the above code was not fully tested, just to give an idea of what I was thinking of. This would then probably end up in a |
I have been trying to avoid unreleased/Git repository crates recently, but for this I can get back into it so as to test and try things out. |
I had to add: use std::io;
use std::pin::Pin;
use std::task::{Context, Poll};
use futures::{AsyncRead, AsyncWrite};
use futures_util::io::AsyncReadExt;
use futures_util::io::AsyncWriteExt; hopefully this is all as expected. |
Please don't clutter this issue with unrelated support requests, let's keep this here for API discussion. (Your problem is that you use a |
Any specific other APIs people want to see wrapped in something more Rust'y with futures, which parts (other than the obvious socket / file APIs) should get focus? |
The code deals with SocketClient and SocketConnection, is something needed for SocketListener? |
The code contains something for |
Your code is, unsurprisingly, an awful better than what I was putting together. Thanks. |
Given that the field connection in SocketConnection is private, is there a need for a method such as get_remote_address to get details of the remote end of the connection that results from the accept/incoming? Also does SocketListener need a close method? |
Yes, such API should be added.
How would that behave different from dropping it? async-std/tokio |
The documentation for |
That would happen as part of dropping, or do you see a reason to do it explicetly? |
The line:
is giving the error:
UPDATE: Seemingly solved by adding the statement: use std::future::Future; |
I think I have been distracted by the comments about calling close: the comments are actually C and not Rust focused. As long as close automatically gets called at end of scope, there is no problem. |
As at 2020-05-08, the line: for connection in server.incoming() { given the error:
whilst the line: for connection in server.incoming().await { (I am just experimenting here) gives the error:
|
Needs to be |
@sdroege Thanks. I was looking at the wrong incoming() documentation for ideas. I am wondering if it might be worth creating a temporary Git repository for this as a work in progress pending getting stuff into the gio repository. |
I was going to create a fork of the gio repo when I got time for it. |
It appears that: for socket_connection in server.incoming().next().await { blocks permanently even when a connection request arrives. :-( Update: Actually, it is exactly the opposite, the loop terminates immediately. Further update: Or rather the await causes the task to terminate: the loop never terminates but the task stops. And more: Putting the sequence: let mut incoming = server.incoming();
let next = incoming.next();
let x = next.await;
eprintln!("mock_avr850: got an x."); into an async function which gets started with a spawn_local, the code up to the await executes but the await silently terminates the task without the output being printed. |
Needs some debugging then, please go ahead :) I didn't actually test the above code much, it was only meant as an illustration how the API could look like / be implemented. |
The code can be found here for now: https://github.com/sdroege/gio-futures @russel This also doesn't have the bug anymore that you noticed, see the example in |
I am switching to using this Git repository rather than the version I had in my repository. I'll send in issues as (if) I come across them. This requires using the Git repositories for gdk-pixbuf, glib, gio, and gtk, which is fine per se. Though it seems that the |
That's intentional, it could never return |
Compared to async-std/tokio it's rather verbose and inconvenient to use. Something like the following, inspired by the beforementioned APIs and how gio works. We would then step by step extend this for other types and with more functions.
Opinions? CC @russel @GuillaumeGomez @EPashkin
The text was updated successfully, but these errors were encountered: