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

Remove ioctl from TcpIpChannel #59

Closed

Conversation

LasseRosenow
Copy link
Collaborator

@LasseRosenow LasseRosenow commented Oct 14, 2024

This changes the TcpIpChannel implementation in the following way

  • ioctl.h => sys/select.h
  • Use unistd.h for close instead of shutdown, which is not available in RIOT

The rationale behind this is to improve compatibility with platforms such as zephyr or RIOT which don't have full POSIX support.

This PR is a draft because I didn't have time to test it yet. There might be implementation bugs.

(I had some problems with compiling the example applications in examples/posix)

@LasseRosenow LasseRosenow changed the title Remove unistd and ioctl from TcpIpChannel Remove ioctl from TcpIpChannel Oct 14, 2024
Comment on lines +152 to +153
int select_result = select(socket + 1, &read_fds, NULL, NULL, &timeout);
if (select_result <= 0) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we actually need to check how much data is there before we read? Since this is running in a separate thread, we want it to block on recv and return with as much data is available. What is gained from checking how much data is there before the read?

(I know that this was there before your edits, and perhaps @tanneberger can answer better?)

@erlingrj
Copy link
Collaborator

Great to see that you are already contributing code Lasse. I think the CI ight fail because the PR is coming from your fork. Could you try just filing it from a branch in this repo. I think you have the necessary access.

@LasseRosenow
Copy link
Collaborator Author

It seems you are correct, I will close this in favor of #61

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.

3 participants