Chapter 20: build a web server #584

steveklabnik · 2017-03-30T22:06:38Z

The first half is here; second half coming tomorrow.

@Kimundi

This is based on @Kimundi's scoped_threadpool crate, which is excellent. There are some small differences since we don't use scoped threads.

steveklabnik · 2017-03-31T17:52:26Z

Here's the draft. The only thing I didn't write was some kind of concluding statement; I'm assuming we'll add that after.

r? @carols10cents

paulsmith · 2017-03-31T18:07:30Z

second-edition/src/ch20-00-unnamed-project.md

+```
+
+A `TcpListener` allows us to listen for TCP connections. We've chosen to listen
+to the address `127.0.0.1:8008`. The first four digits are an IP address


Typo: 8008 should be 8080

I would love to see TLS included as part of this chapter as well.

Not doable, as that certainly requires an extra crate. :(

steveklabnik · 2017-03-31T19:04:06Z

second-edition/src/ch20-00-unnamed-project.md

@@ -1 +1,1732 @@
 # Un-named project


I left this the same for now, as we're gonna have to split it up anyway and figured i'd modify as few files as possible

steveklabnik · 2017-03-31T19:04:25Z

second-edition/src/ch20-00-unnamed-project.md

+
+This error is fairly cryptic. And that's because the problem is fairly cryptic. Basically,
+in order to call a boxed `FnOnce`, it needs to be able to move itself out of the box. But
+the compiler doesn't understand that this is okay to do.


cc rust-lang/rust#28796 (comment)

Uhhh... This is quite unfortunate. As a new rustacean, I would probably feel like:

great! now I read the book and understand the language and felt that I can just go implement something. But already in the first non-trivial example there are footguns that I would not have been able to figure out on my own.

While as an experienced Rustacean, I know this is untrue, it does not leave a good impression. Is there no way to get around this issue in another fashion?

There is not.

I'm torn, as in, I do like showing that Rust isn't perfect, but I also hear you.

You could get around this by making this a Box<FnMut> or Box<Fn>. Obviously that's less general though.

I like bstrie's suggestion on the issue:

Use it as an example of how Rust is still a work-in-progress, and provide an on-ramp for people who have finished the book to come work on Rust itself. :)

coder543 · 2017-03-31T19:23:54Z

second-edition/src/ch20-00-unnamed-project.md

+the plan of attack:
+
+1. `ThreadPool` will hold on to a sending side of a channel.
+2. Each `Worker` will hold on to a recieving side.


recieving -> receiving

coder543 · 2017-03-31T19:24:00Z

second-edition/src/ch20-00-unnamed-project.md

+2. Each `Worker` will hold on to a recieving side.
+3. The `execute` method of `ThreadPool` will then send the closure it wants
+   to execute down the sending side of the channel.
+4. The `Worker` will loop over its recieving side, and when it gets a job,


recieving -> receiving

coder543 · 2017-03-31T19:24:20Z

second-edition/src/ch20-00-unnamed-project.md

+create our new channel, and then have the pool hang on to the sending end.
+
+If you compile this, it will work, but still have warnings. Let's try passing
+the recieving end into our workers. This won't compile yet:


recieving -> receiving

coder543 · 2017-03-31T19:31:32Z

second-edition/src/ch20-00-unnamed-project.md

+
+Here, `Job` is now holding a trait object; specifically, a boxed closure. We
+then send that `job` down the sending end of the channel. Sending may fail;
+we use `unwrap` to ignore the error.


Does unwrap really ignore the error? To ignore it, we could just let _ =. Unwrapping let's us safely bring down the system if something goes wrong, rather than continuing to try to run jobs and ignoring that they aren't actually running.

You're right that this could be worded better, I mean "in the moment to not care about it", but if it happens, it certainly won't be ignored.

coder543 · 2017-03-31T19:35:47Z

second-edition/src/ch20-00-unnamed-project.md

+Finally, we use `call_box` instead of invoking the closure directly.
+
+This is a very sneaky, complicated trick. Don't worry too much if it doesn't make perfect
+sense; someday, it will be completely un-needed.


un-needed -> unnecessary?

coder543 · 2017-03-31T19:38:26Z

second-edition/src/ch20-00-unnamed-project.md

+
+We need to adjust the `ThreadPool` to send `Message`s rather than `Job`s.
+
+```


``` -> ```rust,ignore

not sure what the ignore does

coder543 · 2017-03-31T19:38:55Z

second-edition/src/ch20-00-unnamed-project.md

+Inside of our `Worker, instead of receiving a `Job`, we get a `Message`. We then
+execute the job if it's a `NewJob`, and break out of our `loop` if it's `Terminate`.
+
+```


``` -> ```rust,ignore

steveklabnik · 2017-03-31T19:39:10Z

It prevents the example from being run as a test :)

…

On Fri, Mar 31, 2017 at 3:38 PM, Josh Leverette ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In second-edition/src/ch20-00-unnamed-project.md <#584 (comment)>: > +} +``` + +First, we have a new `Message` enum. We have two kinds of messages: "here's a new +`Job`" and "please terminate execution." + +```rust,ignore +struct ThreadPool { + threads: Vec<Worker>, + sender: mpsc::Sender<Message>, +} +``` + +We need to adjust the `ThreadPool` to send `Message`s rather than `Job`s. + +``` ->rust,ignore not sure what the ignore does — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#584 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsiiUTn8LfFqY1qCeiXBTQR3xtMPyLks5rrVYygaJpZM4Mu-3b> .

SirVer · 2017-03-31T21:06:25Z

second-edition/src/ch20-00-unnamed-project.md

+}
+```
+
+Inside of our `Worker, instead of receiving a `Job`, we get a `Message`. We then


`Worker -> `Worker`, i.e. a missing closing `

SirVer · 2017-03-31T21:15:08Z

second-edition/src/ch20-00-unnamed-project.md

+
+There is still more we could do here; for example, our `ThreadPool` is not
+inherently tied to HTTP handling, so we could extract it into its own submodule,
+or maybe even its own crate!


I'd expect here a sentence alla: Of course there are already very good http server crates and also production ready thread pool implementations on crates.io, so no need to reinvent the wheel in the first place.

We did mention at the beginning of the chapter that there are crates we could use for this; i'm going to expand a bit more there. There's nothing wrong with reinventing the wheel in order to learn how wheels work :)

SirVer · 2017-03-31T21:17:31Z

Sorry for the drive by review - I was just curious in the new books last chapter and had some thoughts :). Please ignore what does not seem appropriate.

carols10cents

I'm not quite done with reading this whole chapter but i need to switch contexts for a bit and i don't want to lose this review

carols10cents · 2017-04-01T15:13:08Z

second-edition/src/ch20-00-unnamed-project.md

@@ -1 +1,1732 @@
 # Un-named project
+
+It's been a long journey, but here we are! It's the end of the book. Parting is


https://en.wikipedia.org/wiki/The_Monster_at_the_End_of_This_Book%3A_Starring_Lovable%2C_Furry_Old_Grover

i read this book so many times as a kid

carols10cents · 2017-04-01T15:16:11Z

second-edition/src/ch20-00-unnamed-project.md

+```
+
+A `TcpListener` allows us to listen for TCP connections. We've chosen to listen
+to the address `127.0.0.1:8008`. The first four digits are an IP address


"the first four digits" i would read as 1, 2, 7, and 0, which I don't think is what you meant.... ok to reword this as "the part before the colon"?

carols10cents · 2017-04-01T15:19:19Z

second-edition/src/ch20-00-unnamed-project.md

+networking, people will often talk about "binding to a port", and so the
+function is called `bind`. Finally, it returns a `Result<T, E>`; binding may
+fail. For example, if we had tried to connect to port 80 without being an
+administrator. Since we're writing a basic client here, we're not going to worry


another thing that might happen is if there are 2 things listening at the same port, like accidentally starting up two instances of this program, right? might be worth using as an example here since it's entirely possible, wdyt?

basic client should be basic server

carols10cents · 2017-04-01T15:20:42Z

second-edition/src/ch20-00-unnamed-project.md

+```
+
+The `incoming` method on `TcpListener` gives us an iterator that gives us a
+sequence of streams, more specifically, `TcpStream`s. This struct represents an


we're probably going to need definitions of "stream" and "connection" here

carols10cents · 2017-04-01T15:21:15Z

second-edition/src/ch20-00-unnamed-project.md

+```
+
+Right now, "handling" a stream means `unwrap`ping it to ignore any further
+errors, and then printing a message. Let's try this code out! First invoke


what kind of errors might a stream have?

done. that was really annoying to find; i need to write better docs :(

carols10cents · 2017-04-01T17:41:34Z

second-edition/src/ch20-00-unnamed-project.md

+we use `unwrap` to ignore the error.
+
+Now that we've got the sending side working, let's write the logic of the worker.
+Here's a first attempt, but it won't quite work:


i think liz is going to be frustrated by all the non-compiling examples in this chapter, but i'm not sure what to do about it....

yeah it's a big refactor so :/

carols10cents · 2017-04-01T17:45:20Z

second-edition/src/ch20-00-unnamed-project.md

+```rust,ignore
+let thread = thread::spawn(move ||{
+    loop {
+        let job = job_receiver.lock().unwrap().recv().unwrap();


looks like you've changed the signature of Worker::new from fn new(id: u32, job: Arc<Mutex<mpsc::Receiver<Job>>>) -> Worker { to fn new(id: u32, job_receiver: Arc<Mutex<mpsc::Receiver<Job>>>) -> Worker { by this point, I think this should actually be done when we added the Arc Mutex, then the placeholder body of Worker::new needs to change at that point too

carols10cents · 2017-04-01T17:45:46Z

second-edition/src/ch20-00-unnamed-project.md

+
+// and then change this code
+impl Worker {
+    fn new(id: u32, job: Arc<Mutex<mpsc::Receiver<Job>>>) -> Worker {


job should change to job_receiver in the signature and body here, see comment later

carols10cents · 2017-04-01T17:47:07Z

second-edition/src/ch20-00-unnamed-project.md

+
+Here, we first call `lock` on the `job_receiver` to acquire the mutex, then
+`unwrap` to panic on any errors, then `recv` to receive a `Job` from the
+channel. A final `unwrap` moves past those errors as well.


plz expand on the different kinds of errors we could get from lock and recv respectively and what they'd mean, so that the reader could choose to handle them more gracefully if they want to enhance this program and if it's appropriate

carols10cents · 2017-04-01T17:48:52Z

second-edition/src/ch20-00-unnamed-project.md

+
+The call to `recv` blocks; that is, if there's no job yet, it will sit here
+until one becomes available. The `Mutex<T>` makes sure that only one Worker
+at a time tries to request a job.


does this mean that the first thread to get the lock holds it until it gets a job? i think so.... i kind of want some print statements in here so that we can see this all happening when it's running

not only that but https://github.com/Kimundi/scoped-threadpool-rs/blob/master/src/lib.rs#L117-L122

I wasn't sure what level of detail was appropriate here.

hnnnngggg ok i think people who have done this sort of thing before might notice that the lock is being held longer than it needs to be, but people who haven't probably won't and it would probably be too much information for them.

wait, if we were seeing that behavior, wouldn't calls to /sleep block the next thread from picking up any other requests? i'm not seeing that behavior...

where "that behavior" = locking the jobs for the time it takes to run a job

yeah, i am not sure about this. i thought because it was a temporary, this is okay, but i was not actually sure.

I guess it doesn't matter since we're not gonna mention it anyway :)

carols10cents · 2017-04-02T00:13:55Z

second-edition/src/ch20-00-unnamed-project.md

+
+This error is fairly cryptic. And that's because the problem is fairly cryptic. Basically,
+in order to call a boxed `FnOnce`, it needs to be able to move itself out of the box. But
+the compiler doesn't understand that this is okay to do.


I like bstrie's suggestion on the issue:

Use it as an example of how Rust is still a work-in-progress, and provide an on-ramp for people who have finished the book to come work on Rust itself. :)

carols10cents · 2017-04-02T00:17:58Z

second-edition/src/ch20-00-unnamed-project.md

+This is a very sneaky, complicated trick. Don't worry too much if it doesn't make perfect
+sense; someday, it will be completely un-needed.
+
+With this trick, our thread pool is in a working state! Give it a `cargo run`, and make


Ok are we going with "thread pool" or "threadpool"? You've used both....

thread pool

carols10cents · 2017-04-02T00:20:41Z

second-edition/src/ch20-00-unnamed-project.md

+}
+
+// we use this instead of (job.job)();
+job.job.call_box();


This line goes in Worker::new, right? I'll do the // ...snip... thing and put it in context, just want to be sure

carols10cents · 2017-04-02T00:28:33Z

second-edition/src/ch20-00-unnamed-project.md

+Worker 2 got a job; executing.
+```
+
+Success! We now have a threadpool executing connections asynchronously.


wdyt about, either here or somewhere else, looking for a request to GET /long etc, and if we see that, sleeping for 30s to simulate a long-running request? Then we could make other requests and see that they're not blocked on the long one, and see that the thread that's handling the long request isn't handling the other requests? I just want to be able to see and prove to myself that this is working :)

and we can add that in above to motivate this change

carols10cents · 2017-04-02T00:34:45Z

second-edition/src/ch20-00-unnamed-project.md

+
+Because we only have a `&mut` in `drop`, we cannot actually call `join`, as `join`
+takes its argument by value. What to do? Well, we already have a way to represent
+"something or nothing", and that's `Option<T>`. Let's update the definition of


wait what i'm lost... how does "we cannot actually call join, as join takes its argument by value" then imply that we should use Option????

reading on, that's not really the logic that i understand here: we need to use Option because we need to be able to take the thread out of the worker and leave None in its place, like we did in the OOP chapter with the statefield, right?

carols10cents · 2017-04-02T00:54:13Z

second-edition/src/ch20-00-unnamed-project.md

+
+```rust,ignore
+struct ThreadPool {
+    threads: Vec<Worker>,


Can we change the threads field on ThreadPool to Workers at this point? It started hurting my head later on, especially in the drop implementation, where we were doing for worker in self.threads; worker.thread and i couldn't keep track of what was what :-/

sure thing (i was switching between them as i wrote this...)

carols10cents · 2017-04-02T00:55:20Z

second-edition/src/ch20-00-unnamed-project.md

+
+We need two loops here. Why? Well, if we send a message and then try to join,
+it's not guaranteed that that worker will be the one that gets that message.
+We'd then deadlock. So we first put all of our `Terminate` messages on the


Can you talk through the deadlock situation a little bit more?

carols10cents · 2017-04-02T00:59:13Z

second-edition/src/ch20-00-unnamed-project.md

+We need two loops here. Why? Well, if we send a message and then try to join,
+it's not guaranteed that that worker will be the one that gets that message.
+We'd then deadlock. So we first put all of our `Terminate` messages on the
+channel, and then we join on all the threads.


How are we guaranteed to send exactly one Terminate message to each worker? Because the Terminate message causes the worker to stop listening for more requests immediately, right? So another worker would have to be the one to pick up the Terminate message?

Is there a case where a Worker would have terminated already, before getting a Terminate message? (we do have unwraps everywhere lol) What would happen then, if we send more Terminate messages than workers? sending the last Terminate message would panic then, right?

Could we talk about this or why this isn't possible if i'm wrong? :)

How are we guaranteed to send exactly one Terminate message to each worker? Because the Terminate message causes the worker to stop listening for more requests immediately, right? So another worker would have to be the one to pick up the Terminate message?

Yup!

Is there a case where a Worker would have terminated already, before getting a Terminate message? (we do have unwraps everywhere lol)

Yeah 😓

What would happen then, if we send more Terminate messages than workers? sending the last Terminate message would panic then, right?

Sending it wouldn't, but when the pool gets dropped, the join for that thread would return Err, and that unwrap would panic. In this case, our program is ending anyway... maybe we should not unwrap that final join. Dunno.

carols10cents · 2017-04-02T01:07:08Z

second-edition/src/ch20-00-unnamed-project.md

+///
+/// # Panics
+///
+/// The `new` function will panic if the size is zero.


Oh also, doc comments in main.rs aren't used, which further helps the case i was going to make that we should have a small main.rs and be doing most of this code in lib.rs, i'm starting to feel itchy with everything being in main.rs

carols10cents · 2017-04-02T01:17:17Z

second-edition/src/ch20-00-unnamed-project.md

+
+```rust,ignore
+struct Job {
+    job: Box<FnOnce() + Send + 'static>,


Potentially a bad idea but I want to see what you think: we haven't talked about type aliases at all yet. What if we add a section on type aliases to chapter 19 (which you mentioned felt light, this would make it a tiny bit more meaty), and then reuse that knowledge here to make Job be a type alias for Box<FnOnce() + Send + 'static> instead of a struct with a job field holding that type?

The job.job business was kind of bothering me, so this idea is somewhat an attempt to eliminate that.

fun trivia fact: the original code I am building this off of does use a type alias here, called Thunk. I thought it was a little jargon-y and am generally ambivalent about aliases. But yeah, this could work.

boooo i dont think the type alias is going to work (or work as nicely as i was thinking) because of the FnBox trick we have to do

WAIT NEVERMIND I GOT IT TO WORK I UNDERSTAND EVERYTHING NOW

carols10cents · 2017-04-02T01:19:07Z

Ok, done now :) I'm happy to take care of any of these things, but if you've got time to help next week and want to take care of them, that would be awesome. I'll pick up whatever you haven't taken care of late next week, unless you register disagreement by then :)

gnzlbg · 2017-04-02T09:51:28Z

second-edition/src/ch20-00-unnamed-project.md

+function is called `bind`. Finally, it returns a `Result<T, E>`; binding may
+fail. For example, if we had tried to connect to port 80 without being an
+administrator. Since we're writing a basic client here, we're not going to worry
+about handling these kinds of errors, and so `unwrap` lets us ignore them.


no ? in main :(

plietar · 2017-04-02T20:56:20Z

second-edition/src/ch20-00-unnamed-project.md

+}
+```
+
+Here's the idea: we loop through each of our `threads`, using `&mut` because `self` is


Isn't iter_mut more idiomatic ?

i don't believe so, i'm open to either

everything should be fixed now i think

matthewjasper

It's so nice that this book has project chapters to show how a more complete rust project looks. I haven't gone through this chapter as closely as I have on some of the others, but these are the things I noticed trying to 'follow along at home', and some thoughts on the ending.

I guess this is also a good time to say thank you so much for spending all the time writing, editing, rewriting and taking feedback for this book! It's been great seeing this book develop. 👍 ❤️

matthewjasper · 2017-05-07T16:44:48Z

second-edition/src/ch20-01-single-threaded.md

+
+    let get = b"GET / HTTP/1.1\r\n";
+
+    let start = &buffer[..get.len()];


This seems to be reinventing starts_with?

nice catch 😅

matthewjasper · 2017-05-07T21:38:50Z

second-edition/src/ch20-04-storing-threads.md

+        }
+
+        ThreadPool {
+            threads: threads,


I guess the shorthand for this is being avoided for now.
Edit: and there are places in the chapter where the shorthand goes from being usable to no being usable, so maybe it's not really worth it here.

only because it wasn't stable when i wrote this ;using the shorthand is 👍

Edit: and there are places in the chapter where the shorthand goes from being usable to no being usable, so maybe it's not really worth it here.

Actually I decided to change the names of variables so that the shorthand is usable in all but one place-- I really like this change because we changed the type being sent over the channel from Job to Message, so job_sender/job_receiver weren't even what they said they were by the end :) Now they're just sender/receiver though!

matthewjasper · 2017-05-07T21:47:21Z

second-edition/src/ch20-04-storing-threads.md

+
+impl Worker {
+    fn new(id: usize) -> Worker {
+        let thread = thread::spawn(|| { });


Space inside { }?

matthewjasper · 2017-05-07T22:31:13Z

second-edition/src/ch20-05-sending-requests-via-channels.md

+    pub fn new(size: usize) -> ThreadPool {
+        assert!(size > 0);
+
+        let (job_sender, job_receiver) = mpsc::channel::<Job>();


Explicit type for clarity? It seems it can be inferred.

i thought it couldn't but I might be wrong

It can be inferred! Neat, I guess because the ends get passed into functions that have the types.

matthewjasper · 2017-05-07T22:36:49Z

second-edition/src/ch20-06-graceful-shutdown-and-cleanup.md

+impl Worker {
+    fn new(id: usize, job_receiver: Arc<Mutex<mpsc::Receiver<Message>>>) ->
+        Worker {
+        // ...snip...


I don't think this code should have been snipped: it's changed to involve a match.

Yup I messed up!

matthewjasper · 2017-05-07T22:40:02Z

second-edition/src/ch20-06-graceful-shutdown-and-cleanup.md

+                        println!("Worker {} got a job; executing.", id);
+
+                        job.call_box();
+                    },


Commas after } in match blocks?

That's what I prefer. Has the style team ruled on this for rustfmt yet? We should probably just run rustfmt on everything right before publishing....

matthewjasper · 2017-05-07T22:47:45Z

second-edition/src/ch20-06-graceful-shutdown-and-cleanup.md

+- Add more documentation to `ThreadPool` and its public methods
+- Add tests of the library's functionality
+- Change calls to `unwrap` to more robust error handling
+- Use `ThreadPool` to perform some other task rather than serving web requests


Try using a library from crates.io to create a similar web server? 😄

matthewjasper · 2017-05-07T22:49:46Z

second-edition/src/ch20-06-graceful-shutdown-and-cleanup.md

+Well done! You've made it to the end of the book! We'd like to thank you for
+joining us on this tour of Rust. You're now ready to go out and implement your
+own Rust projects. Remember there's a community of other Rustaceans who would
+love to help you with any challenges you encounter on your Rust journey.


Maybe mention other resources? Most of the obvious ones get mentioned somewhere in the book though.

Yeah, i'll think about this when we revise chapter 1.

matthewjasper · 2017-05-07T22:49:56Z

second-edition/src/ch20-06-graceful-shutdown-and-cleanup.md

+
+Well done! You've made it to the end of the book! We'd like to thank you for
+joining us on this tour of Rust. You're now ready to go out and implement your
+own Rust projects. Remember there's a community of other Rustaceans who would


Or help with other people's?

carols10cents · 2017-05-15T16:12:30Z

I guess this is also a good time to say thank you so much for spending all the time writing, editing, rewriting and taking feedback for this book! It's been great seeing this book develop. 👍 ❤️

I want to heart this but gh still hasn't implemented reactions on review summary comments :P

Thank you so much for all your excellent feedback!!!! Are you coming to RustConf or Rust Belt Rust this year by chance? I'd love to buy you a {beverage/dessert/something of choice} in thanks!!!

carols10cents · 2017-05-15T20:00:23Z

I think this is ready for another review @steveklabnik @matthewjasper anyone else?

steveklabnik · 2017-05-15T21:00:50Z

second-edition/src/ch20-03-designing-the-interface.md

+
+Then create a new directory, *src/bin*, and move the binary crate rooted in
+*src/main.rs* into *src/bin/main.rs*. This will make the library crate be the
+primary crate in the *hello* directory; we can still run the binary in


I'd still probably keep it src/main.rs personally. Why'd you use the secondary binary location?

$ mv src/bin/main.rs src/main.rs $ cargo doc --open error: cannot document a package where a library and a binary have the same name. Consider renaming one or marking the target as `doc = false`

We demonstrate doc comments, so I want to be able to build docs. It's either move main into bin or fuss with Cargo.toml, and I went with moving the file :-/

sooo is that a orrrrr....?

steveklabnik · 2017-05-16T15:40:31Z

…

On Tue, May 16, 2017 at 10:35 AM, Carol (Nichols || Goulding) < ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In second-edition/src/ch20-03-designing-the-interface.md <#584 (comment)>: > +that we're doing in our web server. Once we've got the thread pool library +written, we could use that functionality to do whatever work we want to do, not +just serve web requests. + +So create *src/lib.rs* that contains the simplest definition of a `ThreadPool` +struct that we can have for now: + +<span class="filename">Filename: src/lib.rs</span> + +```rust +pub struct ThreadPool; +``` + +Then create a new directory, *src/bin*, and move the binary crate rooted in +*src/main.rs* into *src/bin/main.rs*. This will make the library crate be the +primary crate in the *hello* directory; we can still run the binary in sooo is that a [image:

] orrrrr....? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#584 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsipadDMQK_WT8Z-lKZUJd5N0fcoUbks5r6bRFgaJpZM4Mu-3b> .

steveklabnik · 2017-05-16T19:51:28Z

:confetti-ball:

steveklabnik added 2 commits March 30, 2017 18:06

Chapter 20: build a web server

12a2be6

Build a threadpool.

122d9d2

This is based on @Kimundi's scoped_threadpool crate, which is excellent. There are some small differences since we don't use scoped threads.

paulsmith reviewed Mar 31, 2017

View reviewed changes

add full code

b55c6bf

steveklabnik commented Mar 31, 2017

View reviewed changes

webserver -> web server

6b99be9

coder543 reviewed Mar 31, 2017

View reviewed changes

carols10cents added 2 commits March 31, 2017 15:24

Spellings

89a87c3

Mark png as binary

8db574a

coder543 reviewed Mar 31, 2017

View reviewed changes

More spelling

c242160

coder543 reviewed Mar 31, 2017

View reviewed changes

Fix syntax highlighting and tests

43c2307

SirVer reviewed Mar 31, 2017

View reviewed changes

carols10cents requested changes Apr 1, 2017

View reviewed changes

carols10cents previously requested changes Apr 2, 2017

View reviewed changes

gnzlbg reviewed Apr 2, 2017

View reviewed changes

plietar reviewed Apr 2, 2017

View reviewed changes

carols10cents mentioned this pull request Apr 10, 2017

Drafts to get into beta #614

Closed

16 tasks

steveklabnik added 2 commits April 12, 2017 12:37

added a little list of what we learn

5fd91bc

add more about http and tcp and clients and servers

6c50506

carols10cents added 13 commits April 18, 2017 09:10

Splitting out sections on channels and drop

0ad425f

Rearrange motivation/introduction of thread pool a bit

6e63123

Standardize on unix $ rather than windows >

e2cbfad

Start a library for ThreadPool

eb0c058

I got confused about these file paths and fixed them wrong before

50d9f91

Edits through 20-04

61fa941

Edits to 2/3 of 20-05

18b4149

Spelling

6cc1c62

More edits

eed5f0c

Finish editing 20-05

ec85f9f

I will not reintroduce misspellings I will not reintroduce misspellings

3800d0f

Start of edits on 20-06

35c76d1

Finish editing 20-06

713e633

matthewjasper reviewed May 8, 2017

View reviewed changes

carols10cents added 6 commits May 15, 2017 12:31

Ooops don't reimplement starts_with lol

97dedb8

Use struct field shorthand

4dc8eb3

Remove space inside empty curly braces

a4f4ed2

Type the channel is sending can be inferred

80a396b

Add another suggestion from matthewjasper

10158ea

Mention helping with other people's

38904a8

steveklabnik commented May 15, 2017

View reviewed changes

carols10cents approved these changes May 16, 2017

View reviewed changes

carols10cents merged commit 9742298 into master May 16, 2017

carols10cents deleted the ch20 branch May 16, 2017 18:43


		We need to adjust the `ThreadPool` to send `Message`s rather than `Job`s.

		```

		@@ -1 +1,1732 @@
		# Un-named project

		It's been a long journey, but here we are! It's the end of the book. Parting is


		let get = b"GET / HTTP/1.1\r\n";

		let start = &buffer[..get.len()];

Chapter 20: build a web server #584

Chapter 20: build a web server #584

Conversation

steveklabnik commented Mar 30, 2017

steveklabnik commented Mar 31, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

steveklabnik Mar 31, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coder543 Mar 31, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

steveklabnik commented Mar 31, 2017 via email

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

SirVer commented Mar 31, 2017

carols10cents left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

carols10cents commented Apr 2, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

matthewjasper left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

steveklabnik Mar 31, 2017 •

edited

Loading

coder543 Mar 31, 2017 •

edited

Loading