Re: [racket-users] Multiple places listening to a TCP port [was: Racket application servers]

[Matthew Flatt]

At Thu, 29 Nov 2018 18:06:05 -0500, Philip McGrath wrote:
> > 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?

Yes, that's right.

-- 
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.

Re: [racket-users] Multiple places listening to a TCP port [was: Racket application servers]

[Philip McGrath]

On Sun, Nov 25, 2018 at 6:13 PM Matthew Flatt  wrote:

> At Sat, 24 Nov 2018 19:39:19 -0500, Philip McGrath wrote:
> > On Fri, Nov 23, 2018 at 5:44 PM George Neuner 
> 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
 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.

Re: [racket-users] Multiple places listening to a TCP port [was: Racket application servers]

[Matthias Felleisen]

FWIW, when I started CS in 1980 at Arizona, Griswold had moved on to Icon and 
no longer seemed to care about Snobol. He definitely thought of Icon as an 
improvement over Snobol the way Racket improves on Scheme. — Matthias





> On Nov 26, 2018, at 9:59 PM, George Neuner  wrote:
> 
> 
> On 11/26/2018 4:44 PM, Neil Van Dyke wrote:
>> I don't know how Snobol dropped out of awareness.  I almost never heard of 
>> it in the MS-DOS, Windows, or Unix workstation circles, even before Perl, 
>> though occasionally you'd see an interpreter on a BBS or freeware/shareware 
>> list.
> 
> That's funny because it definitely was around.  I know for a fact it was on 
> SunOS and Ultrix, and there was a BSD version on VAX.  In the micro world 
> there were CP/M and Apple II versions.  MSDOS had at least 2 implementations: 
> SNOBOL4 itself, and a descendant language called "Icon"[*].  Icon later was 
> ported to both Macintosh and Windows 3.
> 
> 
> [*] an unfortunate name given the imminent rise of WYSIWYG user interfaces.  
> Icon was not a graphical tool - it was a script language and runtime.  The 
> name "Icon" was a nod to SNOBOL's beginnings as a symbolic computation 
> language.
> 
> 
>> The most memorable mention I recall was a grad student in the '90s remarking 
>> that (IIRC) Andy van Dam wanted to teach Snobol to undergrads.  This being 
>> funny in a "he might be right, but it's lol so random, and he wouldn't 
>> actually do that" kind of way. (AvD did lead a grad school class, around 
>> '95, to evaluate candidate languages for CS intro use.  We looked at many 
>> languages, including Java when it was called Oak, but I don't recall anyone 
>> championing Snobol.)
> 
> It's interesting even that someone would joke about that late. AFAIK, SNOBOL4 
> was only taught from the late 60's to early 70's. Like other things that work 
> well, it was evangelized by its users.
> 
> I am not aware of any metrics on how many users it had, but given the size of 
> the computing community in 1980, even a few 10s of thousands would have been 
> considered phenomenal.  Unlike today where something is a failure if it's not 
> on a million smartphones within 6 months.  
> 
> 
>> Could Snobol be another case study of a good technology that fell out of 
>> use, such as due to accidents of products or user bases separate from the 
>> innate merits of the technologies?  Lisp and Smalltalk and Prolog and 
>> Betamax people could sympathize. :) 
> 
> I am pretty sure that was the situation.
> 
> 
>> Are there any new lessons we can learn about adoption, or any lessons of 
>> linguistics?  (Maybe one of the best string-processing features of Snobol is 
>> a Racket procedure or syntax extension waiting to happen. Or maybe 
>> understanding the twist of fate of Snobol will enlighten 
>> "https://www.neilvandyke.org/racket-money/; as to why we're not all rich 
>> already. :)
> 
> Adoption?  Probably not.  Things become popular if they appear at the right 
> time, work well enough, and get some publicity.  Perl (predated Linux but) 
> was able to capitalize on the Linux craze, and crucially an O'Reilly book 
> about Perl appeared just  a few years after the initial release.  When 
> SNOBOL4 was first released, there were no micros or personal workstations, 
> operating systems were proprietary, and nobody was writing books about 
> computing.
> 
> Linguistics?  Maybe.  One of SNOBOL4's main uses was automated document 
> analysis and translation.  Human languages are contextual, and even though 
> vocabulary is restricted, it's likely that no CF tool will ever be able to 
> faithfully translate [regardless of how much time or power you throw at it].  
> But SNOBOL4 made significant inroads because it's complex recursive pattern 
> language was able to do hard things like identifying indirect objects, 
> pronoun references, etc. - things that made analyzing text possible.
> 
> As for implementing SNOBOL4 in Racket, I would think it should be relatively 
> easy.  After all, it has already been done in C, Java, Python, JavaScript, 
> etc.  I certainly could do SNOBOL4 as a standalone implementation, but I have 
> not yet grokked how to create (#lang ...) languages integrated into Racket - 
> and that's the way it should be done.
> 
> YMMV,
> George
> 
> -- 
> 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.

-- 
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.

Re: [racket-users] Multiple places listening to a TCP port [was: Racket application servers]

[George Neuner]

On 11/25/2018 6:13 PM, Matthew Flatt wrote:

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.


AFAIK, a single process can't open any listen port more than once - so 
exposing  SO_REUSEPORT  wouldn't necessarily help.  However, I seem to 
recall Jay McCarthy mentioning that TCP ports can be sent over place 
channels.  Since listen gives you a new port for each connection, it 
should be possible to have a centralized listener offloading processing 
to a place.


But this still isn't the same as with multiple processes.  A listen port 
has a fixed sized queue of waiting connections - it's adjustable within 
boundaries, but can't be exceeded by a single process.  With multiple 
processes, the queue is magnified by the number of processes - each 
process can queue that number of connections.  It's an important 
distinction if the connection load is very heavy.


George

--
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.

Re: [racket-users] Multiple places listening to a TCP port [was: Racket application servers]

[Matthew Flatt]

At Sat, 24 Nov 2018 19:39:19 -0500, Philip McGrath wrote:
> On Fri, Nov 23, 2018 at 5:44 PM George Neuner  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.

-- 
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.