Skip to content

Conversation

@aviatesk
Copy link
Member

@aviatesk aviatesk commented Dec 4, 2025

- Fix unsafe_read to correctly calculate remaining bytes (nb - written) and use proper destination offset (to + written)
- Fix potential race condition in peek by checking buffer under lock

Written with Claude.

EDIT: Turns out I just ended up crafting noises. Picked up one minor improvement from it.

- Fix `unsafe_read` to correctly calculate remaining bytes (`nb -
written`) and use proper destination offset (`to + written`) - Fix
potential race condition in `peek` by checking buffer under lock

Written with Claude.
@aviatesk aviatesk requested a review from serenity4 December 4, 2025 18:11
Copy link
Collaborator

@serenity4 serenity4 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be 95% LLM noise. It was a bit hard to understand what it's supposed to do and why. Does it address the issues that you are observing? It would be nice to have a link to the original error to see what needs fixing/what to look for.

The addition on line 121 of checking that the task is still running in unsafe_read seems worth adding, but I would oppose the rest of the changes as it is.

src/testing.jl Outdated
Comment on lines 100 to 121
written = 0
written = UInt(0)
while written < nb
bytesavailable(io) > 0 || (yield(); continue)
@lock io.lock begin
n = @lock io.lock begin
(; buffer) = io
n = min(length(buffer), nb)
GC.@preserve buffer begin
unsafe_copyto!(to, pointer(buffer), n)
n = min(UInt(length(buffer)), nb - written)
if n > 0
GC.@preserve buffer begin
unsafe_copyto!(to + written, pointer(buffer), n)
end
splice!(buffer, 1:n)
end
splice!(buffer, 1:n)
written += n
n
end
written += n
if written < nb
# Yield first to give the background task a chance to read more data
yield()
eof(io) && throw(EOFError())
Copy link
Collaborator

@serenity4 serenity4 Dec 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can see, on a semantic level, the changes:

  • perform multiple unsafe_copyto! instead of waiting for the buffer to have all the data then copy in one go.
  • check for eof(io) at the end of every iteration.

But nothing related to

Fix unsafe_read to correctly calculate remaining bytes (nb - written) and use proper destination offset (to + written)

and we should already correctly calculate the right number of bytes.

The rest seems to be mostly noise. If the issue was that we need an extra istaskdone(io.task) && throw(EOFError()) in the loop, I'm all good with it, but through the LLM noise that single line appears to be the only change worth noting and the rest just increases the complexity for no reason AFAIU.

@aviatesk
Copy link
Member Author

aviatesk commented Dec 4, 2025

Thanks for the review. Looks like I submitted a low-quality PR because I didn't properly review Claude's output. Sorry for that. I made these changes while debugging #684.

Actually, test_provider.jl still fails on my local machine (especially with remarks not emitting correctly for some reason). But since it passes on CI, I guess it might be a non-determinism issue from AsyncIO, and that why I asked Claude for investigating the potential issues of this code. But it could just be a problem with my machine, though.

About this PR, you're right, I wrote it randomly. I just thought it would be a straightforward fix and created this PR taking what Claude saying, but I should have reviewed these changes more carefully..

@aviatesk aviatesk changed the title Fix bugs in AsyncIO implementation improve AsyncIO robustness Dec 4, 2025
@serenity4
Copy link
Collaborator

No harm done! Apologies if I may have sounded a bit salty in my comments.

I ran the tests on my machine with Julia 1.12.2, and they all pass without any issues. If you ever happen to have a reproducer, or just see it fail on CI, I can take a look at potential issues. The whole point of this AsyncIO wrapper was to avoid hangs or other annoyances due to having IO interactions across tasks, so if it somehow causes weird bugs, that should definitely be fixed.

Co-authored-by: Cédric Belmant <[email protected]>
@aviatesk
Copy link
Member Author

aviatesk commented Dec 5, 2025

No harm

No, I totally get that it's annoying to review random code, whether it's AI-generated or not, so I'm just sorry I put you through that.
About those failing tests on my machine, they're still happening. But since they're not failing in CI, it might be something with my local preference settings. Anyway, if I can reproduce it on CI or in a whatever sharable way, I'll let you know.

@aviatesk aviatesk merged commit 7203dea into master Dec 5, 2025
12 of 13 checks passed
@aviatesk aviatesk deleted the avi/fix-asyncio branch December 5, 2025 18:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants