SockMan #64
SockMan #64
Conversation
|
Yo! There are two problems here:
Here is a patch: sv2sockman.diff.txt The changes to |
|
Thanks. I'll apply your changes as well as the test clarifications. |
53f852b to
d0ae2f6
Compare
|
Folded all of it into #50! Left a few followup questions there. Additionally I fixed a few locking warnings and implemented |
| * @param[in] buf Destination to write bytes to. | ||
| * @param[in] len Write up to this number of bytes. | ||
| * @param[in] flags Same as the flags of `recv(2)`. Just `MSG_PEEK` is honored. |
There was a problem hiding this comment.
@vasild these first two params are in/out right?
There was a problem hiding this comment.
Did you mean to comment on bitcoin#30988? This branch is stale (though not sure if this method changed since).
There was a problem hiding this comment.
#50 uses SockMan and I try to keep it freshly rebased.
There was a problem hiding this comment.
ok ill start tracking there, just had a few quesitons for @vasild as I'm consuming DynSock in my branch now too
There was a problem hiding this comment.
@vasild these first two params are in/out right?
The first one buf is an out yes, the method writes data to that. The second one is in - the method only reads it to know up to how many bytes it can write without overflowing. Noted in:
| std::unique_ptr<Sock> DynSock::Accept(sockaddr* addr, socklen_t* addr_len) const | ||
| { | ||
| return m_accept_sockets->Pop().value_or(nullptr); | ||
| } |
There was a problem hiding this comment.
@vasild would it make sense to modify sockaddr here like you do for ZeroSock::Accept()? Otherwise all client connections appear to originate from [::]:0
No description provided.