Set close-on-exec and similar by default.

[de-vri-es]

This is my proposal for #111: the default behavior is to enable close-on-exec and SOCK_NOSIGPIPE on the relevant platforms, but there are *_raw functions that really only wrap a single syscall.

[de-vri-es]

Note that this PR doesn't re-add the workaround for missing SOCK_CLOEXEC support, in line with rust-lang/rust#74606. That keeps the code much simpler.

[Thomasdezeeuw]

I'm not sure about the raw, I want to think about this a bit more, but currently don't have the time for it.

[de-vri-es]

Some alternatives I can think of: plain, custom, with_custom_flags, uncooked, transparent.

Although out of all of those, raw still sounds best to me.

[Thomasdezeeuw]

I don't want to accept this as is. With Type::no_inherit from pr #124, this can be completely handled in src/socket.rs, essentially copying the example code (removed in this pr) into a method. I want the sys module be only methods that are direct wrappers around system calls with minimal overhead and some helper functions.

I'll change Socket::new to the method I decided above.

[de-vri-es]

I don't want to accept this as is. With Type::no_inherit from pr #124, this can be completely handled in src/socket.rs, essentially copying the example code (removed in this pr) into a method.

That's not true though, at-least not without putting more #[cfg(...)] in src/socket.rs, since you would have to enable platform specific flags in the calls. That kinda defeats the purpose of having sys/unix.rs and sys/windows.rs. It would also requires the all feature just for correct initialization.

It's also not a fix for accept4, which again is platform specific.

I want the sys module be only methods that are direct wrappers around system calls with minimal overhead and some helper functions.

It's still only calling a single syscall, just with the correct platform specific flags. That seems fine for a sys module to me.

/edit: Except for apple targets I suppose, but it's still performing platform specific actions.

[Thomasdezeeuw]

@de-vri-es I created pr #125 for Socket::new.

[Thomasdezeeuw]

The relevant commit is fdc4fd4.

[de-vri-es]

I'm having a hard time contributing this way. I can understand feedback and requests for changes, but now you're leaving my PR open without feedback for 11 days and then break my PR without letting me implement feedback.

I would appreciate a more contribution friendly workflow :(

[Thomasdezeeuw]

I'm having a hard time contributing this way. I can understand feedback and requests for changes, but now you're leaving my PR open without feedback for 11 days and then break my PR without letting me implement feedback.

I'm sorry about this. As I said I wanted to this think about the pr (and the bigger picture of flags set to et etc.) a bit more, but I've been rather busy and socket2 is simply not among my highest priorities. This is even further complicated because I'm in the process of refactoring the entire crate, of which only roughly 20% is currently done.

I would appreciate a more contribution friendly workflow :(

I'll try to improve this in the future, hopefully once the rewrite is done this will be much improved. I did something similar with Mio, but I did the refactoring offline and only contributed the changes back once it was complete. Perhaps it was a mistake to take a different approach to socket2.

[de-vri-es]

I'm sorry to hear that. If the refactor is not finished though, why can't you review this and give me time to implement feedback before continuing with the refactor? There is no need to rush anything, including the review. It's just the new PRs that you're opening that make it impossible for me to contribute.

Especially if you're pressed for time, you can let me do the legwork..

[Thomasdezeeuw]

I'm sorry to hear that. If the refactor is not finished though, why can't you review this and give me time to implement feedback before continuing with the refactor? There is no need to rush anything, including the review. It's just the new PRs that you're opening that make it impossible for me to contribute.

I created pr #125 just as an example, it's not complete, it doesn't even compile. I just wanted to show the direction I was thinking in, it's often easier to show with (pseude/broken) code that in English for me.

Especially if you're pressed for time, you can let me do the legwork..

If you can help review #124 and rebase this pr on it with, with the suggested changes in line with #125 that would be great.

[de-vri-es]

Ah, that does sound much better. I'll make some time for that :)

[de-vri-es]

Ok, rebased and processed the suggestions.

The PR also hides the public set_cloexec() and set_no_inherit() behind the all feature, for consistency with other platform specific APIs.

Platform specific APIs needed by new() and accept() now have a pub(crate) variant that starts with an underscore. pair() is already gated behind the all feature, so it wasn't needed for that.

/edit: Also added tests to check the default flags (and their absence for new_raw()).

[Thomasdezeeuw]

I'm afraid this isn't quite what I was looking for. I'm added a bunch of inline comments.

Also please don't use the Self key when returning or creating type, it requires someone to needlessly look up what type is being created, just use the concrete type name.

[de-vri-es]

I'm afraid this isn't quite what I was looking for.

You could just leave this bit off. The in-line comments are quite clear on their own, and that kind of remark makes me feel somewhat unappreciated.

Anyway, I think I processed most of the comments. I marked the processed ones as resolved, and we probably need to discuss the remaining ones a bit more.

[Thomasdezeeuw]

@de-vri-es I've rebased this on my branch in #134.

[de-vri-es]

I'm sorry, but I'm done here. I can't contribute to a repository where the maintainer does things like this.
Even though I explicitly brought it up before, you still went ahead and broke my PR for a third time, leaving this without review again for 11 days.

You may have rebased my PR, but you also modified it. Now it's up to me to search for modifications and comment if I don't agree with the changes.

Finally, I would hugely appreciate it if you use a more human friendly tone in your feedback. I'd much prefer "Could you X", "I'd prefer Y" over "Revert X", "Do Y". I'm not a robot after all.

I wish you the best of luck with this repo, but I can't contribute to it like this.

[Thomasdezeeuw]

I'm sorry, but I'm done here. I can't contribute to a repository where the maintainer does things like this.
Even though I explicitly brought it up before, you still went ahead and broke my PR for a third time, leaving this without review again for 11 days.

Really... we've been through this. I don't have all the time in the world you review your pr.

You may have rebased my PR, but you also modified it. Now it's up to me to search for modifications and comment if I don't agree with the changes.

It's very common to accept a PR with changes. I did it in the same commit, but I also could have made it another commit, really who cares?

Finally, I would hugely appreciate it if you use a more human friendly tone in your feedback. I'd much prefer "Could you X", "I'd prefer Y" over "Revert X", "Do Y". I'm not a robot after all.

I've been doing too long to say please, especially since a thank you is rarely around the corner. I think you're taking these things way to personal. I've always kept my comments about your code and never made it personal, I can't say the same about your comments (which made it tiring you work you to be honest, but I never mentioned that did I?).

I wish you the best of luck with this repo, but I can't contribute to it like this.

Thank you. Even though we might not see eye to eye now I also wish you the best of luck.