samples: sockets: socketpair: sample application and docs

[cfriedt]

Support for the socketpair(2) system call was recently added for 2.3.0.

This change adds a sample application that demonstrates how it can be used.

Fixes #25527

[zephyrbot]

All checks are passing now.

checkpatch (informational only, not a failure)

-:333: WARNING:EMBEDDED_FUNCTION_NAME: Prefer using '"%s...", __func__' to using 'main', this function's name, in a string
#333: FILE: samples/net/sockets/socketpair/src/socketpair_example.c:156:
+				printf("main: closed fd %d\n",

- total: 0 errors, 1 warnings, 311 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

Your patch has style problems, please review.

NOTE: Ignored message types: AVOID_EXTERNS BRACES CONFIG_EXPERIMENTAL CONST_STRUCT DATE_TIME FILE_PATH_CHANGES MINMAX NETWORKING_BLOCK_COMMENT_STYLE PRINTK_WITHOUT_KERN_LEVEL SPDX_LICENSE_TAG SPLIT_STRING VOLATILE

NOTE: If any of the errors are false positives, please report
      them to the maintainers.

Tip: The bot edits this comment instead of posting a new one, so you can check the comment's history to see earlier messages.

[cfriedt]

Hehe... so looks like I'm implementing nanosleep(2). Probably better to do that in a separate PR ;-)

@pfalcon saw #24730

Looks like newlib doesn't have its own implementation and just makes a syscall. Doesn't look like Zephyr has such a syscall atm. I was thinking of kludging it together with k_sleep(), k_msleep(), and k_cycle_get().

[cfriedt]

I'd like to leave this as a draft until #25559 and #25572 are merged.

[pfalcon]

I'd like to leave this as a draft until #25559 and #25572 are merged.

To set expectations right, this may be as well after the 2.3 release (and surely, not e who decides).

[cfriedt]

I'd like to leave this as a draft until #25559 and #25572 are merged.

To set expectations right, this may be as well after the 2.3 release (and surely, not e who decides).
Of course ;-)

[jukkar]

Thanks, looks good!

[pfalcon]

From #25528 (comment)

@pfalcon saw #24730

And I didn't saw this and following lines. Because they were edited into an already posted comment, and the original content of that comment is what I got in email and considered it read. I mentioned this issue lately elsewhere. Please avoid editing comments for adding new information, post it as a new comment instead. It's ok to post a bunch of comments in row (if it's needed). (And I for one edit my comments, but only to fix typos/ambiguous wording).

[cfriedt]

It looks like there was a copy-paste error made several years ago that is breaking this PR.

c8aa657

typedef struct pthread_attr_t {
...
} pthread_attr_t;

[pfalcon]

@cfriedt: I don't see a copy-paste error there. It's quite a natural way to use the same name for both struct and typedef, but if you hint that it plays bad with #define which is supposed to target just one of those names, then yeah, could be.

[cfriedt]

@pfalcon - it's inconsistence. Elsewhere in the file there is e.g.

typedef struct pthread_mutex {
...
} pthread_mutex_t;

The actual error here is specific to nrf52bsim I think. I didn't see the entirety of the error message... but posix types are defined twice.

-include /home/buildslave/src/github.com/zephyrproject-rtos/zephyr/arch/posix/include/posix_cheats.h

[pfalcon]

nrf52bsim is another instance of CONFIG_ARCH_POSIX, aka native_posix issue-alike.

Anyway, feel free to propose a fix. As usual, submitting it as a separate PR raises chances for it to be processed sooner rather than later (but I assume, @carlescufi is busy with high-priority fixes by now).

[cfriedt]

@carlescufi - sample application and docs would be good to accompany socketpair for 2.3.0. I'm sure it's too late now, but just thought I would throw it out there.

[pfalcon]

@carlescufi - sample application and docs would be good to accompany socketpair for 2.3.0. I'm sure it's too late now, but just thought I would throw it out there.

Given that socketpair() is just introduced for 2.3, we hardly can make it worse for anyone with further changes, only better. @carlescufi, adding 2.3 milestone to help you not forget about this case ;-).

[carlescufi]

I am merging this because it's a sample that demonstrates a new feature that was introduced in 2.3.0.