-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve handling of non-blocking try-connect #106
Conversation
Memory usage after merging this PR will be: Memory Reportaction_microstep_test_c
action_test_c
delayed_conn_test_c
event_payload_pool_test_c
event_queue_test_c
nanopb_test_c
physical_action_test_c
port_test_c
reaction_queue_test_c
request_shutdown_test_c
shutdown_test_c
startup_test_c
tcp_channel_test_c
timer_test_c
|
src/platform/posix/tcp_ip_channel.c
Outdated
if (new_socket >= 0) { | ||
self->client = new_socket; | ||
FD_SET(new_socket, &self->set); | ||
static lf_ret_t check_if_socket_is_writable(int fd) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This and other function should maybe start with TcpIpChannel_
. At least this is our current code style as I can remember?
I personally prefer to have static functions start with an underscore, it makes it more clear, which functions are actually public for me and in the IDE, but better have it consistent through the project
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. The TcpIpChannel_
prefix was initially meant for naming functions that had many implementations for different "subclasses". They are meant for implementing the corresponding functions in the public API (which is the function pointers on the struct). For purely static functions it might be different. But it might get messy if we dont pick a single convetion. I will follow your suggestion for now
@@ -280,19 +403,6 @@ static void TcpIpChannel_free(NetworkChannel *untyped_self) { | |||
} | |||
|
|||
void TcpIpChannel_ctor(TcpIpChannel *self, const char *host, unsigned short port, int protocol_family, bool server) { | |||
FD_ZERO(&self->set); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Moving this to the reset function is very nice
LF_ERR(NET, "Connect failed errno=%d", errno); | ||
self->client_connect_in_progress = false; | ||
TcpIpChannel_reset_socket(self); | ||
return LF_TRY_AGAIN; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At first it was a little bit confusing for me that in progress and failed both return TRY_AGAIN
, but I guess it does somewhat make sense from the NetworkChannel
perspective.
In both cases we need to try again.
But I see one argument why maybe a differentiation could make sense here.
In the Zephyr example you sleep for some time if you get a TRY_AGAIN
, but this only makes sense for the EINPROGRESS
case from what I can see.
In case of a reset_socket
we could just immediately try again.
So maybe return LF_IN_PROGRESS
For EINPROGRESS
and only wait for that case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And then also maybe we could be more transparent and instead of LF_TRY_AGAIN
return a LF_CONNECTION_FAILED
? The user of the API can then decide if they want to try again or not I guess?
But I am also okay with keeping TRY_AGAIN
. It has the advantage of telling the user what to do ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another way would be LF_CONNECTION_IN_PROGRESS_TRY_AGAIN
and LF_CONNECTION_FAILED_TRY_AGAIN
But maybe these are getting a little bit long now :D
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I went for LF_IN_PROGRESS
and LF_TRY_AGAIN
, on Zephyr we do a short sleep before trying again.
Looking good to me, I left some small comments :) |
Memory usage after merging this PR will be: Memory Reportaction_microstep_test_c
action_test_c
delayed_conn_test_c
event_payload_pool_test_c
event_queue_test_c
nanopb_test_c
physical_action_test_c
port_test_c
reaction_queue_test_c
request_shutdown_test_c
shutdown_test_c
startup_test_c
tcp_channel_test_c
timer_test_c
|
This PR was triggered by not getting the Zephyr federated example to work on our boards anymore. It does several things:
select
to see that socket is writable before checking error message. Possibly closing socket and reopening if it failed.