On Sun, Nov 25, 2018 at 6:13 PM Matthew Flatt <mfl...@cs.utah.edu> wrote:
> At Sat, 24 Nov 2018 19:39:19 -0500, Philip McGrath wrote: > > On Fri, Nov 23, 2018 at 5:44 PM George Neuner <gneun...@comcast.net> > wrote: > > > > > Multiple (identical) server instances running on the same machine can > > > listen for connections on the same network port - an incoming client > call > > > will be connected to only one of them. You only need to use different > > > ports when services are not interchangeable [i.e. it matters which one > you > > > are talking to]. > > > > > > [...] > > > > I didn't know this, and it sounds useful! Unfortunately, this > functionality > > doesn't currently seem to be exposed at the Racket level. [...] > > > > It looks like the `reuse?` argument to `tcp-listen` corresponds to > > `SO_REUSEADDR` rather than `SO_REUSEPORT`. [...] > > > > It seems like this might be a useful feature in Racket, but I'm not sure > of > > what would be needed to expose it in a good way. > > An alternative to exposing `SO_REUSEPORT` would be to allow TCP > listeners to be sent across place channels, so multiple places in same > Racket process could accept connections from the same listener. That > would only work for place-based parallelism, but it would be portable > and straightforward to implement --- and I'm happy to add it if anyone > would find that capability useful. > Allowing TCP listeners to be sent across place channels sounds much more promising than exposing the portability issues with `SO_REUSEPORT`—I, for one, am a big fan of the fact that Racket makes it easy to write portable code. It also seems like it would be a step toward adding built-in support for parallelism to the web server, which is something I'd be interested in working on eventually (i.e. definitely not this week). While looking into this I read the discussion <https://lwn.net/Articles/542718/> about adding `SO_REUSEPORT` to the Linux kernel, and one of the motivations discussed was performance, which did seem worth considering in advance. Specifically, apparently if you > accept on a single listener socket from multiple threads … the proportion > of connections accepted per thread tends to be uneven under high connection > load (assuming simple event loop: while (1) { accept(); process() }, wakeup > does not promote fairness among the sockets. We have seen the > disproportion to be as high as 3:1 ratio between thread accepting most > connections and the one accepting the fewest. With so_reusport the > distribution is uniform. > Am I right that this is essentially what Racket would be doing internally if multiple places were blocked on `tcp-accept` with the same TCP listener? (This is a bit low-level for me.) Even if so, I think being able to send TCP listeners across place channels would probably still be useful, especially since most of us will never see what Google would call "high connection load." -Philip -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
