@jeapostrophe could you also check the r-linq package? I have the same issue.

@mflatt I’d posted this a couple weeks ago and it scrolled by: https://racket.slack.com/archives/C06V96CKX/p1545239011337500 I was wondering if you had any quick reaction? Even just, “Yep, that sounds as-expected”, or, “You’re probably doing something wrong”. (The TL;DR is udp-receive! seems to lose datagrams around the time of a major GC.)

I haven’t actually tried any experiments, but it would make sense for the OS to drop a Racket socket’s packets around full-GC time if they’re being sent quickly from a different process. (Since Racket won’t check for messages during a GC, the socket’s buffer could fill up, and a full GC can take a while.)

@mflatt That makes sense. The major GCs were something like 60–80 ms. Thanks! Confirming what’s reasonable to expect, is a huge help.

I tried incremental collection and that made the lossage more even, less bursty.

I might try doing the “lower level” rx in a dedicated place, using an allocating-avoiding style. OTOH not sure how much less loss and therefore fewer retransmits that would really get; maybe not worthwhile.

@trajafri Just got r-linq

@mbutterick it means that while trying to evaluate the promise, it attempted to force the promise again

[samth@hermes:~ plt] r
Welcome to Racket v7.1.0.10.
> (define p (delay (force p)))
> (force p)
; force: reentrant promise `p' [,bt for context]

Awesome! Thank you!