I’m experiencing what I think is a typechecker bug in typed racket’s apply function. My code works when I disable typechecking, but I run into typechecker issues otherwise.

Here’s a minimal working example : https://stackoverflow.com/q/58470724/1412255

Is this the expected behavior a known issue? If neither of those two then I’ll open an issue on github

@p.kushwaha97 I’m not 100% sure, but I think Typed Racket is pointing out that set-union requires at least one argument but the (Listof (Setof Symbol)) type you’ve given to l makes no promise that l is not empty. If I change the type annotation to (List (Setof Symbol) (Setof Symbol)) it works.

There can be a thread swap after syncing on the fd evt and before running the handler. So if two threads execute that expression, they could both see that the fd is ready, then one thread reads the available data, and the other thread tries to read and blocks.

I noticed that read-bytes will allocate however many bytes you want to read whether or not the input port contains that many bytes. Initially, I thought this was reasonable, but now I’m not so sure. What I think I’d naturally expect it to do is to allocate at most as many bytes as there are available in the input port plus a little bit of overhead. Am I missing something?

Here’s a little script that shows the problem: https://gist.github.com/Bogdanp/ff6e609f9a6ff964efdd12ff5948a252

xref. https://github.com/racket/web-server/pull/77/commits/fce5058cc42b7dbb51cce99591e7caffd263cb2a and https://github.com/racket/web-server/pull/77/commits/fadf7faa100e726855f4e83e63e57f8778e5434b

Here’s the output that I get from running that script:

$ racket mem.rkt
before
#"hello\n how are you\n"
after
mem delta: 0.039474
#<thread:...ogdan/tmp/mem.rkt:41:5>
before
#"hello\n how are you\n"
after
mem delta: 100.015297
#<thread:...ogdan/tmp/mem.rkt:60:5>

the first delta is from my custom read-bytes/lazy and the second is from read-bytes.

There’s a note about this in the read-string documentation

I totally missed that. Thanks!

It might be possible to do better, but I expect it’s hard while not slowing down the common case or adding races.

I think this is fine as long as it’s documented behavior. I’ll make a PR at some point to try to highlight that note about allocation a bit better. I swear I read the docs for read-string a couple times today and never noticed that note. :smile:

Does my read-bytes/lazy variant seem like a reasonable approach when you want to ensure buffers are only allocated in accordance with how much data there is in the port? Is there something I could be doing better from a performance standpoint?

I worry both about what happens when two threads call that on the same port and about performance for small N

I think I’ll make it branch and use read-bytes when n is small. The parts of web-server-lib I’m using this on don’t read the input port across multiple threads within the span of a single request so I should be fine wrt thread safety. Thanks again!

@popa.bogdanp Have you considered reading N bytes (for some small N), then 2N, then 4N, etc.? You end up allocating roughly twice as much data as turns out to be available, but that kind of strategy scales well in general and avoid races.

@mflatt Matt, there’s a hidden gem (for me) in that last 2010 PLT distribution: non-gui compiles on BeOS. Should have little problem building on the still in active development Haiku OS. What’s the last version of Racket which still builds from the C++ code base without needing a prior Racket scheme binary during the build process (so I don’t run into a chicken / egg problem)?

They all build from C currently

Without needing a prior scheme binary separate from the actual C build?

(Typo above, meant C, not C++)

Right

I compared that approach to this one in a microbenchmark last night and it ended up being about twice as slow as this one for the inputs I had tried (10, 256 and 1024). I’ll run a few more tests tomorrow against some real world data to see if there is a significant difference or not. Thanks!

Of course. Thanks!

Does anyone know the last version of Racket which could run on Windows 2000? Thanks.

Right now, I installed the last one before the name change (PLT Scheme 4.2)