syscall for socketpair(2)

[cfriedt]

Is your enhancement proposal related to a problem? Please describe.

A typical means of inter-thread communication is to use a socket pair.

Although it may be a slightly heavyweight method of inter-thread communication for Zephyr, it would facilitate porting applications.

Describe the solution you'd like
I would like to see an implementation of socketpair(2) in Zephyr.

Describe alternatives you've considered

Additional context

[pfalcon]

A typical means of inter-thread communication is to use a socket pair.

I wouldn't call it a "typical" way.

Although it may be a slightly heavyweight method of inter-thread communication for Zephyr, it would facilitate porting applications.

Sounds good. Would give even more weight to the proposal if you gave example of application(s) which could be ported using it.

[cfriedt]

@pfalcon - I often use it as a means of cancelling a worker thread where sockets are used with select(2) or poll(2). If you add one end of the socketpair to readfds or pollfds, then it will unblock a blocking select or poll.

[pfalcon]

I often use it as a means of cancelling a worker thread where sockets are used with select(2) or poll(2).

Then I'd suggest to look into #22863 , and help to review/test it. eventfd() would be much more efficient way to signal events (vs passing data) between threads.

[cfriedt]

I often use it as a means of cancelling a worker thread where sockets are used with select(2) or poll(2).

Then I'd suggest to look into #22863 , and help to review/test it. eventfd() would be much more efficient way to signal events (vs passing data) between threads.

Interesting. Yeah, I guess eventfd() would satisfy my criteria, although it is 100% Linux specific / not portable to other OS's (AFAIK). The nice thing about socketpair() is that it is POSIX and pulled in with <sys/socket.h>, so it Just Works (TM) everywhere.

It seems eventfd also only supports writing uint64_t instead of arbitrary data, which is somewhat inflexible.

I do think that a pipe(2) implementation would be nice for Zephyr too..

Personally, I don't think having more options is a bad thing.

[pfalcon]

I guess eventfd() would satisfy my criteria, although it is 100% Linux specific / not portable to other OS's (AFAIK)

To the best of my knowledge, yes.

It seems eventfd also only supports writing uint64_t instead of arbitrary data, which is somewhat inflexible.

I'd say the basic function of eventfd is to just get out of poll() call. In such usage, you could (almost) always just fallback to (simple) pipe() call. Passing any data is an extra, advanced feature (well, still achievable with pipe() of course).

I do think that a pipe(2) implementation would be nice for Zephyr too..

+1

Personally, I don't think having more options is a bad thing.

I think so too, but:

1. More work for you ;-)
2. If we do it, let's do it: a) without obvious security issues; b) truly POSIX compatible (implementing just a subset of functionality for starters is OK, just that subset should be compatible).
3. It's also more work for maintainers, so p.2 is important.

There was also p.4, but I forgot what it was, and hopefully it won't apply to your PRs ;-).

Thanks!