Sorry if I wasn't clear, but I am looking for a more general answer! I would like to know in which case it is useful (to other people) and discuss it's value comparatively to writing interfaces to other languages.
I had no intention of making the end result useful, but I run into interesting problems.
First, I wanted to make it as pure Rust as possible. I tried to avoid UNIX specific code, and since there is no library with Windows support for asynchronous IO in Rust, I was pushed into spawning thread and blocking waiting for client data. I quickly noticed that the benchmark was way below Redis (around 60% of ops/sec with 50 clients). But then someone point out to me[1] that I was running tests in a machine with two cores, and this actually may be better for machines with multiple cores[2]. I have yet to try it out and benchmark the results.
So far Rust API was disappointing for network operations. For example, `TcpStream.read()`[3] and `TcpListener.incoming()`[4] do not have a timeout. Maybe because its development is driven for Servo and not for servers.
I have thought about doubling down on multithreading and instead of a global database lock as rsedis is using now, having one per key (or some other arbitrary partition), and having concurrent operations, which is hard to do safely in C. But I have not gotten there yet.
> set_timeout has been removed for now (as well as other
> timeout-related functions). It is likely that this may
> come back soon as a binding to setsockopt to the
> SO_RCVTIMEO and SO_SNDTIMEO options. This RFC does not
> currently proposed adding them just yet, however.
And on UDP:
> All timeout support is removed. This may come back in
> the form of setsockopt (as with TCP streams) or with
> a more general implementation of select.
I'm on shaky wifi and my phone, so I can't find a citation for this, but I also believe it was removed due to 1) Rust not having any stable representation of time and 2) needing to shim certain behaviors on some platforms, which we decided wouldn't happen in the first round of stable interfaces.
That said, the lack here certainly hurts, and we did manage to stabilize Duration, paving the way for timeouts to return.
Thanks for the clarification. I wanted to subscribe to rust's internals debates and proposals, but I was not sure how to find them. Should I be looking at https://github.com/rust-lang/rfcs or is there anywhere else?
1. We keep open issues on that repo to track ideas.
2. At some point, someone may decide to formally propose an idea. They may or may not post a "pre-RFC" to internals.rust-lang.org to get early feedback.
3. An actual RFC will get filed at that repo as a PR.
4. The relevant sub team will check it out and comment, and at some point, consensus will be reached either way.
5. The RFC will go to 'last call' for a week, making sure all voices have been heard.
6. Assuming nothing in last call blocks moving forward, the RFC will be accepted.
7. The RFC will be implemented.
So, in short, yes, subscribing to that repo will notify you of the relevant discussions.
IRC is used for quick casual conversation. The internals forum is used for discussion, "pre-RFC", and the like. The rfcs repo is use for actually discussing formal RFCs, as well as wishlist language and library bugs. The rust repo is for the actual implementation of rustc and the standard library itself.
Your comment is interesting to me because although i've only looked at Rust from a distance, its seemingly lack of features related to server side code ( threading , non blocking io and networking api) have made me wait before i actually start coding in that language.
It depends on what you're doing. See https://github.com/jonhoo/volley, which uses blocking IO and 1:1 threads, and we're still damn fast.
There are also libraries like mio that can give you no blocking IO. Rust's standard library is deliberately minimal, exploring the ecosystem a bit is helpful, though admittedly not as easy as it could be. Working on it!
Right. People should realize that there is no latency difference between blocking and non-blocking IO -- in fact there is a small difference in blocking IO's favor. The difference is in throughput when there is a very large number of concurrent requests, namely more than about 10K and certainly more than 2K. If you're serving under 2K concurrent requests, blocking IO is probably a better choice than nonblocking. Of course, the number of concurrent requests you need to serve depends on the time you spend serving each request; Little's Law and all that.
