WIP commit (that may end up deleted in the future) that really slims down the interface and fixes some of the uglyness around the registration stuff github.com/sphaerophoria/ball-machine/commit/fb995b3db2ae66eccde001dd25577479346e157e
Amazing video, currently watching still. I'm pretty new to this stuff but I think node.js uses libuv which is a library that uses epoll/an event loop. When there isn't any work left to do, the loop ends and the node process exits. My question is...when you start a web server, does it add a file descriptor to the list of fds and that fd stays there indefinitely until you close it when doing ctrl-c or something in the terminal? In other words, how does a web server keep the event loop indefinitely running?
It's probably easier to explain if we think about it without the event loop first. A typical server will look like (pseudo code) socket = make_socket(); listen(socket); while (true) { connection = accept(socket); read_or_write_connection(connection); } So we have one socket that sits there listening, and over time new connections come in when people connect to the socket The event loop case isn't any different, except for instead of doing connection = accept(socket) in the main loop, we set up a function callback that accepts the connection and shoves the new connection into our list of events to handle Specific event loops may end up handling this differently. You could shove a wants_shutdown bool in the while condition, you could wait until there is nothing left to poll, and have someone explicitly deregister the socket that is accepting new connections, i'm sure there are other options but I don't want to think about them :P
01:25:35 Is ``` var connection = try self.server.accept(); var echoer = TcpEchoer.init(self.alloc, connection) catch |e| { connection.stream.close(); return e; }; ``` equivalent to ``` var connection = try self.server.accept(); errdefer connection.stream.close(); var echoer = try TcpEchoer.init(self.alloc, connection); ``` or am I misunderstanding `errdefer`? On a side note, `errdefer ` can capture error. Might be useful for lazy catch all error logging.
It's a super subtle difference. I am trying to hand off ownership of the connection to the TcpEchoer. In TcpEchoer.deinit I close the connection, but also do some other stuff. Say we fail to register with the event loop at line 30, if we did the errdefer you're speaking of, we would close the connection once through echoer.deinit at line 25, then again at the errdefer that would be inserted at line 20. I'm actually not sure if double closing is a problem, but double freeing definitely is so I have the habit of ensuring cleanup is only issued one time per object
WIP commit (that may end up deleted in the future) that really slims down the interface and fixes some of the uglyness around the registration stuff github.com/sphaerophoria/ball-machine/commit/fb995b3db2ae66eccde001dd25577479346e157e
Amazing video, currently watching still. I'm pretty new to this stuff but I think node.js uses libuv which is a library that uses epoll/an event loop. When there isn't any work left to do, the loop ends and the node process exits.
My question is...when you start a web server, does it add a file descriptor to the list of fds and that fd stays there indefinitely until you close it when doing ctrl-c or something in the terminal? In other words, how does a web server keep the event loop indefinitely running?
It's probably easier to explain if we think about it without the event loop first. A typical server will look like (pseudo code)
socket = make_socket();
listen(socket);
while (true) {
connection = accept(socket);
read_or_write_connection(connection);
}
So we have one socket that sits there listening, and over time new connections come in when people connect to the socket
The event loop case isn't any different, except for instead of doing connection = accept(socket) in the main loop, we set up a function callback that accepts the connection and shoves the new connection into our list of events to handle
Specific event loops may end up handling this differently. You could shove a wants_shutdown bool in the while condition, you could wait until there is nothing left to poll, and have someone explicitly deregister the socket that is accepting new connections, i'm sure there are other options but I don't want to think about them :P
01:25:35 Is
```
var connection = try self.server.accept();
var echoer = TcpEchoer.init(self.alloc, connection) catch |e| {
connection.stream.close();
return e;
};
```
equivalent to
```
var connection = try self.server.accept();
errdefer connection.stream.close();
var echoer = try TcpEchoer.init(self.alloc, connection);
```
or am I misunderstanding `errdefer`?
On a side note, `errdefer ` can capture error. Might be useful for lazy catch all error logging.
It's a super subtle difference. I am trying to hand off ownership of the connection to the TcpEchoer. In TcpEchoer.deinit I close the connection, but also do some other stuff. Say we fail to register with the event loop at line 30, if we did the errdefer you're speaking of, we would close the connection once through echoer.deinit at line 25, then again at the errdefer that would be inserted at line 20. I'm actually not sure if double closing is a problem, but double freeing definitely is so I have the habit of ensuring cleanup is only issued one time per object
Oh I see. Thank you for the explanation.