Fix incorrect docs/disconnect handling in peer_handler by TheBlueMatt · Pull Request #512 · lightningdevkit/rust-lightning

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt · 2020-02-20T20:14:30Z

The way PeerHandler was written, it was supposed to remove from
self.peers iff the API docs indicate that disconnect_event should
NOT be called (and otherwise rely on disconnect_event to do so).

Sadly, the implementation was way out of whack with reality - in
the implementation, essentially anywhere where PeerHandler
originated the disconnection, the peer was removed and no
disconnect_event was expected. The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

We opt to change the docs, mostly, as well as clean up the
ping/pong handling somewhat.

Frankly I'm not sure if lightning-net-tokio complies with this properly, but I'm gonna update #472 with the correct behavior in a sec.

ariard

ACK 1f53c04 if you don't want to fix comments

TheBlueMatt · 2020-02-21T00:33:27Z

Rewrote a ton of docs, and renamed a few functions to clarify what they do.

The way PeerHandler was written, it was supposed to remove from self.peers iff the API docs indicate that disconnect_event should NOT be called (and otherwise rely on disconnect_event to do so). Sadly, the implementation was way out of whack with reality - in the implementation, essentially anywhere where PeerHandler originated the disconnection, the peer was removed and no disconnect_event was expected. The docs, however, indicated that disconnect_event should nearly only be called, only not doing so when the initial handshake message never completed. We opt to change the docs, mostly, as well as clean up the ping/pong handling somewhat and rename a few functions to clarify what they actually do.

ariard · 2020-02-21T19:00:39Z

ACK faaa4d2

jkczyz · 2020-02-21T20:00:59Z

The docs, however, indicated that
disconnect_event should nearly only be called, only not doing so
when the initial handshake message never completed.

Is this suppose to say "nearly always be called"?

TheBlueMatt · 2020-02-21T20:09:39Z

Oops, yea, the commit message is off there. At least the code comments are right :)

jkczyz

Oops, yea, the commit message is off there. At least the code comments are right :)

Weren't you suppose to give me a chance to review this if assigning it to me? FWIW, I was writing these comments before I noticed it was already merged.

jkczyz · 2020-02-21T20:12:59Z

 /// careful to ensure you don't have races whereby you might register a new connection with an fd
-/// the same as a yet-to-be-disconnect_event()-ed.
+/// the same as a yet-to-be-socket_disconnected()-ed.


I don't understand what the emphasized is saying:
whereby you might register a new connection with an fd the same as a yet-to-be-socket_disconnected()-ed.
Something seems grammatically off or perhaps I'm just not parsing this correctly.

jkczyz · 2020-02-21T20:13:34Z

 	///
 	/// Returns the amount of data which was sent, possibly 0 if the socket has since disconnected.
-	/// Note that in the disconnected case, a disconnect_event must still fire and further write
+	/// Note that in the disconnected case, a socket_disconnected must still fire and further write


jkczyz · 2020-02-21T20:15:26Z

-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to


Drop "obviously". The reason for including the comment is that this behavior is not obvious.

jkczyz · 2020-02-21T23:57:48Z

-	/// more calls to write_event, read_event or disconnect_event may be made with this descriptor.
-	/// No disconnect_event should be generated as a result of this call, though obviously races
-	/// may occur whereby disconnect_socket is called after a call to disconnect_event but prior to
-	/// that event completing.
+	/// more calls to write_buffer_space_avail, read_event or socket_disconnected may be made with
+	/// this descriptor. No socket_disconnected call should be generated as a result of this call,
+	/// though obviously races may occur whereby disconnect_socket is called after a call to
+	/// socket_disconnected but prior to that event completing.


"No disconnect_event" was changed to "No socket_disconnected call" here but later in the comment "event" is still used.
prior to that event completing
Rather than replacing "event" with "call", I'd recommend re-wording to something a little less ambiguous such as:
prior to the former completing

jkczyz · 2020-02-22T00:01:19Z

+/// generate no further read_event/write_buffer_space_avail calls for the descriptor, only
+/// triggering a single socket_disconnected call (unless it was provided in response to a
+/// new_*_connection event, in which case no such socket_disconnected() must be generated and the
+/// socket be silently disconencted).


grammar: must be

jkczyz · 2020-02-22T00:23:39Z

-	/// but must NOT be called if a PeerHandleError was provided out of a new_\*\_connection event!
+	/// This must only be called if the socket has been disconnected by the peer or your own
+	/// decision to disconnect it and must NOT be called in any case where other parts of this
+	/// library (eg PeerHandleError, explicit disconnect_socket calls) instruct you to disconnect


How is the user supposed to differentiate between their own call to disconnect_socket and that of this library?

Hmm, disconnect_socket is different from socket_disconnected - I suppose a user could call disconnect_socket on their own Descriptor, but in general I presumed they wouldn't (and would just call shutdown(2)).

TheBlueMatt · 2020-02-24T16:56:05Z

Weren't you suppose to give me a chance to review this if assigning it to me?

Oops, forgot I assigned you on this one before merging, in any case, not really a big deal either way. Post-merge review is 98% as good as pre-merge review IMO :)

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

TheBlueMatt added this to the 0.0.10 milestone Feb 20, 2020

TheBlueMatt requested a review from jkczyz February 20, 2020 20:14

ariard reviewed Feb 20, 2020
View reviewed changes

Comment threadlightning/src/ln/peer_handler.rs Outdated
Comment threadlightning/src/ln/peer_handler.rs Outdated

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 1f53c04 to edd732eCompare February 21, 2020 00:32

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from edd732e to 6304698Compare February 21, 2020 01:31

TheBlueMatt force-pushed the 2020-02-peer_handler-docs branch from 6304698 to faaa4d2Compare February 21, 2020 01:51

TheBlueMatt merged commit 2be0810 into lightningdevkit:masterFeb 21, 2020

jkczyz reviewed Feb 22, 2020
View reviewed changes

TheBlueMatt mentioned this pull request Feb 24, 2020
Further clean up some comments wrt the peer socket handling API #515
Merged

TheBlueMatt modified the milestones: 0.0.10, 0.0.11 Feb 26, 2020

Uh oh!

Conversation

TheBlueMatt commented Feb 20, 2020

Uh oh!

ariard left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Feb 21, 2020

Uh oh!

ariard commented Feb 21, 2020

Uh oh!

jkczyz commented Feb 21, 2020

Uh oh!

TheBlueMatt commented Feb 21, 2020

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt commented Feb 24, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

TheBlueMatt commented Feb 20, 2020

Uh oh!

ariard left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Feb 21, 2020

Uh oh!

ariard commented Feb 21, 2020

Uh oh!

jkczyz commented Feb 21, 2020

Uh oh!

TheBlueMatt commented Feb 21, 2020

Uh oh!

jkczyz left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TheBlueMatt commented Feb 24, 2020

Uh oh!