On 06/23, Jordan Rife wrote: > > Untested code to illustrate the idea below. Any reason it won't work? > > In theory, I like the idea of unrolling the code a bit here to make > the flow more clear (and to make it clear what's happening to the > locks!). IIRC there was some reason this was hard, but I will think > about it a bit again. > > I also want to make sure things stay relatively consistent between the > UDP and TCP socket iterator code structure. The UDP socket iterators > already do the `goto fill_batch` and `goto again` thing, which is > where I borrowed this from. If we end up diverging here, I'd want to > go back and update the UDP code as well. > > Thanks for the suggestion. I'll take a closer look a bit later and see > if I can work this in. In the meantime, hopefully Martin can chime in > as well. We went back and forth on the code structure quite a bit in > the patch series for UDP socket iterators, so he might have some > opinions here. Martin is OOO so you'll have to wait a bit for his feedback. UDP iterator seems to be more low level to me (with explicit locking), so maybe all this non-unrolled retry logic there is justified, but I haven't looked too deep.
