Share immutable reference in a HTTP Server

Question

I'm currently building a HTTP service exposing actions on a unique object. I already created the central object, with several methods taking immutable &self references, and using internally various efficient synchronization structures to access the data inside (all the code is unsafe-free). My thought was that this would be enough to make it safe to use concurrently.

And then comes the hard part of actually connecting it to a HTTP server. I'm currently trying to use Iron, but I could switch to Nickel.rs or any other if it makes things easier.

Most HTTP server examples I saw used stateless handlers, without any access to local variables. I now understand why: it's near-impossible to do.

Here is an example of what I'd like to do, using Nickel.rs: https://gist.github.com/Gyscos/42510a335098ce935848

Here is a similar failed attempt using Iron: https://gist.github.com/Gyscos/92e56e95baee0ebce78f

The basic idea being that obj only lives for the duration of the scope, but so does server, so it shouldn't be a big deal... right?

Unfortunately each of my attempts failed. When trying to give the server a closure that accesses self.object, I get an error saying that the closure might outlive the reference.

I saw Iron provided a shared memory module with a Read structure. Not only does it look overly complicated for my needs, I also would like to avoid paying the Arc price when I don't need it (I have a clear view of the lifecycle of the object and really don't need to count references).

The current solution I see would be to have a static Object and use that instead of one specific to MyServer, but I'd prefer to avoid this level of ugliness if possible.

I come from golang, where this is not a problem (I could use object-bound methods as handler for that). So my question is: how do you easily access a shared immutable reference from your HTTP handlers in Rust?

Answer 1

Note that I have no prior experience with Nickel or Iron (personally I'm using SCGI so far).

The error I got compiling your Nickel example is:

<nickel macros>:7:9: 7:70 error: captured variable `obj` does not outlive the enclosing closure

The error happens in the following snippet:

server.utilize(router! {
    get "/foo" => |_req, _res| {
        obj.foo();
    }
});

Now, router! is just a fancy macros to wrap your closure in a Middleware, with some additional checks built in. For our investigation we might want to get to the roots and use the Middleware directly.

Unfortunately Nickel explicitly requires the Middleware to have a 'static lifetime. That's a quirk of the Nickel API design and doesn't have much with Rust per se (except for the fact that Rust allows the library to require such things from the user).

I see two options then. First is to use our superior knowledge of the object lifetime (Nickel doesn't know that our object outlives the server but we do) and tell the compiler so. Compiler allows us to show our superiour knowledge with the helpful unsafe and transmute primitives.

Here it is, working: unsafe.rs.

In Rust unsafe means "this piece of code is safe because the programmer said so". Every unsafe piece must satisfy this safety contract between the programmer and the compiler. In this case we know that the object outlives the server so the safety guarantee is maintained.

The second option is to pay the price for tricks that would satisfy the requirements of the Nickel API. Here we use a scoped thread-local storage for this: thread_local.rs.

Bottom line: Nickel API has requirements that make you jump through some hoops to get you where you want. I haven't investigated the Iron API. I have a feeling that you might have a better luck with the lower-level Hyper API.