Ah I see the problem, the one stream flushes the other. For normal seeks this isn't a problem of course because we flush all the streams on the frontend side. But we can't do that when seeking from the streaming thread... well, you can, but synchronization makes an already very complicated bit of logic worse. And synchronization mostly isn't a problem here; it's just this specific race. I believe it should be possible to deal with this without needing the frontends. You can store the stream data in the wg_parser_stream. Once you've done that, though, it's easier not to even store an identifier, but simply a flag "have we called wg_parser_stream_get_buffer()", and then reset that flag on release_buffer() but *also* reset it if a seek ends up flushing the buffer. Then copy_buffer() fails if we get there, which isn't even a problem; in fact we already handle it. This is a bit more declarative, I think. get_buffer() / release_buffer() manage a state that isn't synchronized, so if it can be altered between the two calls, the wg backend should handle that and report that a flush interrupted the sequence, so the caller can give up and start over. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10256#note_131777