On 7/14/22 13:59, Paul Gofman wrote:
On 7/14/22 13:51, Zebediah Figura wrote:
The async may be initiated on the server and delivered to the process (through SIGUSR1)?? before we set async->fixup_type. It might be not likely in practice, but I double verified that it is possible by injecting Sleep(...) before setting fixup type to async structure from server. So I need to make sure that fixup_type in async structure is correctly set before try_recv() can be reached. So idea is, fixup_type is "no fixup" by default, no extra server call is involved in normal case. But if fixup is required and client does not yet know about it server doesn't?? do anything and just returns fixup type with STATUS_MORE_PROCESSING_REQUIRED.
Right, that is annoying, but I guess it's the most reasonable way to solve that problem.
On the other hand... spitballing, but what if instead of returning anything from the server, we used SO_PROTOCOL and SO_TYPE on the client side to check whether it's a DGRAM + ICMP socket?
I am not sure how do I get that info on the client now without asking server? I could do native getsockopt() ofc but IMO it would be not desirable to have extra calls for just every socket operation motivated by this special case. Currently the overhead is contained for this very specific case only.
Yes, getsockopt() on the client side.
Although it means extra syscalls, these should be fast syscalls (they are just retrieving static data from the socket), and socket code is not really one where syscalls themselves are the bottleneck. We're making at least two server calls for every send/recv operation, not counting the actual send()/recv() call. If syscalls are going to be a problem I suspect there are other avenues we'll need to pursue first.