Closed AsakuraMizu closed 3 months ago
Actually you need to send cmsg, right? Add RecvMsg
& SendMsg
then. Although the PR seems OK, I don't think the current implementation should be changed, unless you prove it:)
Just add the two new opcodes if you need cmsg, and we'll see if the old implementation of RecvFrom
& SendTo
need to be refactored.
The main reason stopped me from adding RecvMsg
& SendMsg
may be that it's redundant for io-uring driver and I want to reuse existing opcode... But yes, that's not the case if considering cmsg. I'll open a separate PR for that.
This PR unfies syscalls of
RecvFrom
/RecvFromVectored
/SendTo
/SendToVectored
on all platform.This is needed for a sequent PR that will add support for encoding control information, or rather ancillary data.
Changes
recvfrom
->recvmsg
sendto
->sendmsg
WSARecvFrom
->WSARecvMsg
(see below)WSASendTo
->WSASendMsg
Drawbacks
WSARecvMsg
is not directly exposed by win32 api, but can only be obtained throughWSAIoctl
. This may causeRecvFrom
/RecvFromVectored
unavailable under certain circumstance.new
? Or a seperate constructor likenew_with_cmsg
? Or a new opcode?Alternative solution
Keep current implementation unchanged and add new opcode
RecvMsg
andSendMsg
to unify behaviour and support cmsg.