Messages in this thread | | | Date | Sun, 10 Jul 2022 05:50:30 +0900 | From | Dominique Martinet <> | Subject | Re: [PATCH 3/3] 9p: Add mempools for RPCs |
| |
Christian Schoenebeck wrote on Sat, Jul 09, 2022 at 08:08:41PM +0200: > Mmm, I "think" that wouldn't be something new. There is no guarantee that > client would not get a late response delivery by server of a request that > client has already thrown away.
No. Well, it shouldn't -- responding to tflush should guarantee that the associated request is thrown away by the server
https://9fans.github.io/plan9port/man/man9/flush.html
Order is not explicit, but I read this: > If it recognizes oldtag as the tag of a pending transaction, it should > abort any pending response and discard that tag.
late replies to the oldtag are no longer allowed once rflush has been sent.
But I guess that also depends on the transport being sequential -- that is the case for TCP but is it true for virtio as well? e.g. if a server replies something and immediately replies rflush are we guaranteed rflush is received second by the client?
There's also this bit: > When the client sends a Tflush, it must wait to receive the > corresponding Rflush before reusing oldtag for subsequent messages
if we free the request at this point we'd reuse the tag immediately, which definitely lead to troubles.
> What happens on server side is: requests come in sequentially, and are started > to be processed exactly in that order. But then they are actually running in > parallel on worker threads, dispatched back and forth between threads several > times. And Tflush itself is really just another request. So there is no > guarantee that the response order corresponds to the order of requests > originally sent by client, and if client sent a Tflush, it might still get a > response to its causal, abolished "normal" request.
yes and processing flush ought to get a lock or something and look for oldtag. Looking at qemu code it does it right: processing flush find the old request and marks it as cancelled, then it waits for the request to finish (and possibly get discarded) during which (pdu_complete) it'll wake the flush up; so spurrious replies of a tag after flush should not be possible.
-- Dominique
| |