@ben did you have more comments on https://github.com/racket/rackunit/pull/41 or shall I merge?

go merge!

huzzah!

@mflatt since the rktio changes, this test and a few like it have been failing on and off: http://drdr.racket-lang.org/41014/pkgs/racket-benchmarks/tests/racket/benchmarks/shootout/typed/echo-non-optimizing.rkt

I realize that’s not the most helpful diagnostic information

It’s also not clear if this is a concurrency bug in the tests that just started happening because of your changes, or if it’s a real bug in Racket

@samth Is port number 8888 reserved in DrDr for that test?

It’s the only occurrence of 8888 in racket/racket

I guess non-registration would be a listen error anyway

is there a reservation mechanism in DrDr that I’ve forgotten about?

There’s some list of ports somewhere. Maybe it’s not actually registered other than being in the list.

Looking at that test, though, isn’t there a race between the client starting and the server listening?

it does look like a race

looks like the race was there from the beginning, in https://github.com/racket/racket/blob/d615bccb08274398f347b78a1dd746fe40eb3671/collects/tests/mzscheme/benchmarks/shootout/echo.ss

I’ll add some synchronization

@samth what’s the racket’y way of doing that? I don’t find an equivalent to C/unix select, which is what I’d normally reach for…

@zenspider sync is the equivalent of select

but in this case I think I can just start the client later

no, that’s wrong too

heh. sure.

hrm. sync is on any data you send through the channel?

that’s nice

sync is very nice

and more composable than select

but break is an exception, not some sort of event you send through?

hrm… I can’t tell how the break stuff gets fired

is it more idiomatic to send off a break-thread to all your child threads or to send through some sort of stop datum/event to all of them?

@zenspider why would you need to do that?

thinking of the worker model… fire off a pool of threads to do work, throw them things to work on via sync, then when you’re done shut them down by telling them to stop somehow

might be backwards thinking in racket land

mostly you do thread-per-connection

worker thread pools are more useful when stopping and starting threads is expensive and the resource overhead per-thread is significant

for green thread systems like racket’s that’s typically not the case

right, I use pools of Racket places in some situations

since those are expensive

a package providing a nice place-pool abstraction might be useful

@samth out of curiosity, do you know of any multicore webservers written in racket with places?

I think I’ve seen examples, but not that I recall offhand

@notjack I’ve played around with that idea in the past. I think it would be a bit more straightforward if a tcp listener could be sent over a place channel.

@jaz how’d it work out? my first impression is that it seems like individual places should be responsible for binding to OS ports, but I haven’t really done more than idly daydream about the problem

@notjack I never took the idea very far :slightly_smiling_face:

You definitely could have different places bind to different ports, but then you’d need a proxy layer in front of that, right? You can also leave a single place in charge of accepting connections and handing them off to workers (which is what I was toying around with), but that seems like a bit lightweight of a task for a place.

proxy layer would definitely be needed, yes

specifically I was thinking of how to make a Racket web service with the SEDA architecture https://en.wikipedia.org/wiki/Staged_event-driven_architecture

@ben :party: :party: :party: https://github.com/racket/rackunit/pull/48

@ben http://drdr.racket-lang.org/41016/racket/share/pkgs/redex-test/redex/tests/run-tests.rkt looks like it’s caused by your changes