Apple Network Framework Socket Changes #662
Conversation
|
|
||
| Upon a connection being established, the new socket (either as the result of a `connect()` or `start_accept()` call) | ||
| will not be attached to any event loops. It is your responsibility to register it with an event loop to begin receiving | ||
| notifications. | ||
|
|
||
|
|
||
| #### V-Table |
There was a problem hiding this comment.
Why is this documentation necessary in the public readme? A giant list of functions feels like a distraction
| @@ -717,32 +755,34 @@ Shuts down any pending operations on the socket, and cleans up state. The socket | |||
|
|
|||
| int aws_socket_connect(struct aws_socket *socket, struct aws_socket_endpoint *remote_endpoint); | |||
|
|
|||
| Connects to a remote endpoint. In UDP, this simply binds the socket to a remote address for use with `aws_socket_write()`, | |||
| and if the operation is successful, the socket can immediately be used for write operations. | |||
| Connects to a remote endpoint. In TCP and all Apple Network Framework connections (regardless it is UDP, TCP or LOCAL), this will | |||
There was a problem hiding this comment.
"this will function will not block." reword
Also, I don't know if this is the right wording. Saying "will not block" is misleading; none of them "block" in the sense that they're waiting on some async process to complete, it's just sometimes the socket is immediately usable and sometimes it isn't.
|
|
||
| For LOCAL (Unix Domain Sockets or Named Pipes), the socket will be immediately ready for use upon a successful return. | ||
|
|
||
| int aws_socket_bind(struct aws_socket *socket, struct aws_socket_endpoint *local_endpoint); | ||
|
|
||
| Binds the socket to a local address. In UDP mode, the socket is ready for `aws_socket_read()` operations. In connection oriented | ||
| modes, you still must call `aws_socket_listen()` and `aws_socket_start_accept()` before using the socket. | ||
| Binds the socket to a local address. In UDP mode, the socket is ready for `aws_socket_read()` operations. In connection oriented |
There was a problem hiding this comment.
This if-else conditional behavior bothers me. What happens if you call aws_socket_listen on a bound UDP socket?
| return aws_event_loop_thread_is_callers_thread(channel->loop); | ||
| // As aws_event_loop is not ref-counted, it is possible that the socket read/write callback get triggered after | ||
| // the event loop is released, ignore the function call here. | ||
| if (channel && channel->loop) { |
There was a problem hiding this comment.
This is alarming. I would like to know a lot more about how this is possible: how can you have a channel still alive while its event loop is not?
| @@ -200,6 +200,9 @@ static int s_tls_common_tester_clean_up(struct tls_common_tester *tester) { | |||
|
|
|||
| aws_condition_variable_clean_up(&tester->condition_variable); | |||
| aws_mutex_clean_up(&tester->mutex); | |||
| // wait for socket ref count drop and released | |||
| aws_thread_current_sleep(1000000000); | |||
There was a problem hiding this comment.
Doing this (presumably to prevent memory-still-in-use test failures) is the sign of a much larger problem that could easily make life terrible for us: we don't understand, can't reason about, and/or can't tightly control an async cleanup/shutdown process. We should talk about this with Mike.
Apple Network Framework socket integration
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.