Skip to content

Conversation

@rccarper
Copy link
Contributor

@rccarper rccarper commented Sep 17, 2020

Description of changes:

  • Adding concept of host listeners to the host resolver. Right now, it only supports listening for new addresses being resolved. Ideally, I would like to add the address-removed/expired callback later.
  • This PR originally had a way for grabbing all of the currently cached addresses for a host up-front. That will be in a separate, future PR.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

@rccarper rccarper requested a review from a team September 17, 2020 13:39
@rccarper rccarper marked this pull request as draft September 17, 2020 14:42
@rccarper rccarper force-pushed the resolver-listener branch 2 times, most recently from b328e3e to 2316c79 Compare September 22, 2020 15:26
@rccarper rccarper marked this pull request as ready for review September 22, 2020 15:42
@rccarper rccarper changed the title Resolver listener Host Resolver Listener + Get Cached Addresses for Host Sep 22, 2020
@rccarper rccarper marked this pull request as draft September 28, 2020 19:16
@rccarper rccarper force-pushed the resolver-listener branch 4 times, most recently from 11b90ed to 82a2faa Compare October 23, 2020 19:21
@rccarper rccarper changed the title Host Resolver Listener + Get Cached Addresses for Host Host Resolver Listener Oct 23, 2020
@rccarper rccarper changed the title Host Resolver Listener Adding Support for Host Listeners Oct 23, 2020
@rccarper rccarper marked this pull request as ready for review October 23, 2020 19:52
aws_host_listener_shutdown_fn *shutdown_callback;
void *user_data;

/* Synchronous data, requires host resolver lock to read/modify*/
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's put this in its own struct like we usually do, synced_data most likely

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The rest of the host resolver doesn't use that paradigm so I was worried it might be confusing to mix that in. Might be okay though!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should move toward it over time. For this one, I'd rather break consistency and use the right pattern.

AWS_ASSERT(new_address_list);
AWS_ASSERT(listener_list);

struct aws_linked_list_node *listener_node = aws_linked_list_begin(listener_list);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do we not need to lock around modifying the listener list?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because this listener list is owned by the resolver thread, and only the resolver thread ever modifies it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, can you make that clearer in the comments?

Comment on lines 168 to 169
bool owned_by_resolver_thread;
bool pending_destroy;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's put these at the end of the structure, and bit pack them

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

Comment on lines +233 to +234
* struct aws_host_address *host_address = NULL;
* aws_array_list_get_at_ptr(new_address_list, (void **)&host_address, address_index);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trivial: It's very nice! But to keep the consistent, we may not need this tip?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've found getting a value out of an array list can be somewhat confusing. (I usually crash once!) So I liked calling that out here, but maybe it's overkill.

struct aws_host_listener *aws_host_resolver_add_host_listener(
struct aws_host_resolver *resolver,
const struct aws_host_listener_options *options) {
AWS_ASSERT(resolver);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

trivial: AWS_PRECONDITION? Actually, I am not quite clear about the difference between this two macros..

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was trying to keep this consistent with the existing aws_host_resolver functions. :)

}

int aws_host_resolver_remove_host_listener(struct aws_host_resolver *resolver, struct aws_host_listener *listener) {
AWS_ASSERT(resolver);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above!

/* Synchronous data, requires host resolver lock to read/modify*/
bool owned_by_resolver_thread;
bool pending_destroy;
struct aws_linked_list_node node;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is node also synchronous data? And, why don't we use the structure synced_data.

Copy link
Contributor Author

@rccarper rccarper Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, I was trying to keep this consistent with the way the rest of the host_resolver code is written, ie, no synced_data struct. But I'm going to do the synced_data approach.

/* Structure for holding all listeners for a particular host name. */
struct host_listener_entry {
struct default_host_resolver *resolver;
struct aws_linked_list listeners;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe comment about what's inside the linked_list? Is that struct host_listener?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

* Any time the listener list in the listener entry becomes empty, we remove the entry from the table. This
* includes when a resolver thread moves all of the available listeners to its local list.
*/
/* host_name (string) -> host_listener_entry */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trivial: I feel it might be better to point it out that it stores the pointer of host_listener_entry. But, yeah, basically, it will be only pointers stored in the table. So, ignore this if the other way is more consistent.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's okay but adding the asterisk won't hurt. :)

Copy link
Contributor

@TingDaoK TingDaoK Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, because there was a bug in aws-c-mqtt that we stored pointer in array or table, but we forgot it...


/* Notify all listeners with resolve address callbacks, and also clean up any that are waiting to be cleaned up. */
/* Assumes no lock is held. */
static void s_resolver_thread_update_listeners(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe it will be more clear to comment that the listener_list is a local list, so it doesn't need to be protected by a lock?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will do!

@rccarper rccarper merged commit 3153ad4 into master Nov 4, 2020
@rccarper rccarper deleted the resolver-listener branch November 4, 2020 19:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants