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.
[1] https://github.com/jonhoo/rucache/issues/2
[2] https://github.com/jonhoo/volley/
[3] http://doc.rust-lang.org/1.0.0-beta/std/net/struct.TcpStream...
[4] http://doc.rust-lang.org/1.0.0-beta/std/net/struct.TcpListen...
> Maybe because its development is driven for Servo
> and not for servers.
This is not true at all. If Rust's development were determined by Servo, we would have kept green threads and implemented struct inheritance by now.The reason timeouts were dropped is in the IO/OS reform RFC: https://github.com/rust-lang/rfcs/blob/8fa971a670f9b9bc30f31...
> 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.
EDIT: Oh! I forgot that https://github.com/rust-lang/rfcs/pull/1047 got merged recently. https://github.com/rust-lang/rust/issues/25818 implemented it. http://doc.rust-lang.org/nightly/std/net/struct.TcpStream.ht... shows it implemented on nightly, so you can actually even do timeouts today, just not on the stable channel.
Seems like those parts still need more work.
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!