Skip to content
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

cf-socket: optimize curlx_nonblock() and check its return error #13942

Closed
wants to merge 1 commit into from

Conversation

panjf2000
Copy link
Contributor

@panjf2000 panjf2000 commented Jun 13, 2024

Updates:
Due to the particularity of cf_socket_shutdown(), we've decided not to use sock_nonblocking for cf_socket_shutdown(). Meanwhile, we currently don't check if the socket created by cf_socket_open is non-blocking when connecting, which can lead to unexpected behaviors (blocking connect), therefore, we can leverage sock_nonblocking for these cases. Check out #13942 (comment)


We sometimes need to check if a socket is non-blocking to determine the subsequent actions, such as the cf_socket_shutdown(), which sets the non-blocking flag on the socket and then drains its buffer during a shutdown. It has to use system calls on the socket anyway because there is no way to tell if the current socket is non-blocking, therefore, adding a new flag for struct cf_socket_ctx to indicate if the socket is non-blocking will help us eliminate some redundant system calls.

This PR mainly does two things:

  1. Add the new field sock_nonblocking for cf_socket_ctx and assign proper values to it (also reference it) accordingly
  2. Improve function curlx_nonblock(), make it handle errors properly, and avoid needless system calls

Copy link
Contributor

@icing icing left a comment

Choose a reason for hiding this comment

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

I agree with you that saving syscalls in a filter that is involved heavily is a good idea. But for this change to be reliable, it would really be necessary that the socket is only manipulated by the filter itself.

Unfortunately, this is not the case in libcurl for historical reasons. If you scan the code for calls of curlx_nonblock(), you'll find several locations outside cf-socket.c.

The other observation I had when making the shutdown change in cf-socket is that Windows sometimes seems to block on receives unless the setting to nonblocking just before did indeed succeed. That is the reason for the final receive only being done then.

Due to this, I think using a flag for skipping the curx_nonblock() during shutdown will introduce strange edge behaviour, making it issues hard to debug.

@panjf2000
Copy link
Contributor Author

I agree with you that saving syscalls in a filter that is involved heavily is a good idea. But for this change to be reliable, it would really be necessary that the socket is only manipulated by the filter itself.

Unfortunately, this is not the case in libcurl for historical reasons. If you scan the code for calls of curlx_nonblock(), you'll find several locations outside cf-socket.c.

The other observation I had when making the shutdown change in cf-socket is that Windows sometimes seems to block on receives unless the setting to nonblocking just before did indeed succeed. That is the reason for the final receive only being done then.

Due to this, I think using a flag for skipping the curx_nonblock() during shutdown will introduce strange edge behaviour, making it issues hard to debug.

Thanks for sharing the particularity of cf_socket_shutdown() with non-blocking sockets. So we may not use this new flag in that function, how about only using it on those sockets managed inside cf-socket.c?

@icing
Copy link
Contributor

icing commented Jun 13, 2024

Thanks for sharing the particularity of cf_socket_shutdown() with non-blocking sockets. So we may not use this new flag in that function, how about only using it on those sockets managed inside cf-socket.c?

I might be wrong, but in cf-socket.c I see the flag only set, but never used outside of the shutdown function?

@panjf2000
Copy link
Contributor Author

It's used in cf_udp_setup_quic() if the curlx_nonblock() call in cf_socket_open() failed for some reason. Also, one unusual thing I've noticed is that currently we never check if the socket is non-blocking after calling cf_socket_open(), if the curlx_nonblock() call in cf_socket_open() failed, as I mentioned before, we would get a blocking socket and start a blocking connect() later in cf_tcp_connect() and cf_udp_connect(), which seems like an unexpected behavior. Maybe we can start using this new flag for these cases? Check out the latest code changes.

@panjf2000
Copy link
Contributor Author

Hi @icing, would you take a glance at the latest code changes?

@icing
Copy link
Contributor

icing commented Jun 20, 2024

Hi @icing, would you take a glance at the latest code changes?

Thanks for the ping. Looking at the diff, I like the optimization in nonblock.c which then also does work for the ftp.c use cases.

The ctx->sock_nonblocking I still find unnecessary and, over the socket lifetime, might be wong, as it never gets updated. It is read in a single DEBUGASSERT for QUIC. And since never updated from the start, should always be true.

I think you should remove ctx->sock_nonblocking and the PR is a good optimization.

@panjf2000
Copy link
Contributor Author

Hi @icing, would you take a glance at the latest code changes?

Thanks for the ping. Looking at the diff, I like the optimization in nonblock.c which then also does work for the ftp.c use cases.

The ctx->sock_nonblocking I still find unnecessary and, over the socket lifetime, might be wong, as it never gets updated. It is read in a single DEBUGASSERT for QUIC. And since never updated from the start, should always be true.

I think you should remove ctx->sock_nonblocking and the PR is a good optimization.

Done.

@panjf2000 panjf2000 changed the title cf-socket: add sock_nonblocking for cf_socket_ctx cf-socket: optimize curlx_nonblock() and check its return error Jun 20, 2024
@panjf2000
Copy link
Contributor Author

Hi @icing @bagder, this PR should be good to go, shall we get it merged?

@icing
Copy link
Contributor

icing commented Jun 21, 2024

I am sure @bagder will get right to it after Sweden celebrates midsummer.

@panjf2000
Copy link
Contributor Author

I am sure @bagder will get right to it after Sweden celebrates midsummer.

OK, thanks for the notice! Have a good one!

@bagder bagder closed this in bd8e45c Jun 22, 2024
@bagder
Copy link
Member

bagder commented Jun 22, 2024

Thanks!

@panjf2000 panjf2000 deleted the nonblock-bit branch June 22, 2024 10:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants