Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
RFC: io and os reform: initial skeleton #517
This RFC proposes a significant redesign of the
Note about RFC structure
This RFC was originally posted as a single monolithic file, which made
It has now been split into a skeleton that covers (1) the problem
Other parts of the RFC are marked with
I'm a bit worried about the timeout changes making some uses of the current infrastructure impossible, or maybe just painful/awkward. For example, rust-postgres provides an iterator over asynchronous notifications sent from the database. A method defined on the iterator is
The current setup works fine, if a bit awkwardly: https://github.com/sfackler/rust-postgres/blob/39ad5ff651199287e92aa65ec771267c2f54ea8b/src/message.rs#L279-L285
With the new infrastructure, it'll still be possible to take the same strategy, but probably through some kind of gross hackery like reading the first byte with a timeout, and then passing that byte to the main message read function without the timeout.
What would really be ideal is to have the ability to wait on the socket for data to be ready to read for a certain period of time. Is something like that feasible to implement before 1.0 in a cross platform manner?
I don’t understand why this is undefined behavior and
referenced this pull request
Jan 20, 2015
@aturon given that the eventual goal is to have both blocking and nonblocking implementations of the
Option 1: Call the APIs
Option 2: Call the APIs
Option 3: Call the APIs
I would be happy with either Option 2 or 3, preferring 3. Option 1 just leaves me a little uneasy..
@nodakai I understand the desire to have a "default" io, especially given that its currently the only io. But is it really the right long term philosophy?
If the only current difference is
I've only played around with Nodejs a little, and some of its ideas are definitely controversial, but I think everyone can agree the one thing it did really well was educate all of its users about the difference between blocking and nonblocking io. And yes you could achieve this through documentation.. but similar to immutable by default, syntax/explicitness (at minimal cost) is the best way to educate people.
I've actually been doing a lot of experimentation and work on non-blocking IO and I can say that I do think that blocking IO is a better default model for Rust. It fits much better in with the borrow system for resource management, since the usage of all resources is deterministic relative to the structure of the code, whereas this is not true at all for asynchronous actions.
Additionally, until (if?) Rust has true
The non-clean, extremely low-level bindings for asynchronous IO already exist in the form of mio, and I really think there is no need to integrate these things into