Implemented non-blocking pipe and socketpair

[nikarh]

Motivation:

In Rust ecosystem many libraries rely on a tokio async runtime, which internally requires nonblocking unix pipes (as a fallback for os'es without epoll or kqueue).

This PR contains:

• Added socketpair call. This just creates a IPV4 socket pair yolo ignoring the domain passed as an argument since usually socketpair is used with AF_UNIX, and they are not supported
• Added pipe2 call for nonblocking unix pipes. Depending on the options it delegates either to the original pipe or to sockerpair call. This allows having select, poll, read, write calls for nonblocking pipes without any additional code, because pipe in that case is just a pair of sockets. fcntl is not implemented, since I don't want to touch/break the original pipe implementation in case blocking pipes are needed.
• Fixed read and write calls for pipes, previously they returned buffer length instead of actually read bytes length

[isage]

You'll still ignore it, but I'll leave this note here anyway: async pipes will break (without proper error) if network is in adhoc mode.

[sleirsgoevy]

If this is only for Tokio, maybe it's better to implement kqueue/epoll instead?

[d3m3vilurr]

You'll still ignore it, but I'll leave this note here anyway: async pipes will break (without proper error) if network is in adhoc mode.

• who is you? (nikarh or me?)
• so does @sleirsgoevy 's mention(implement with epoll) be better option to prevent an issue of the adhoc mode?

[isage]

• who is you? (nikarh or me?)

You

• so does @sleirsgoevy 's mention(implement with epoll) be better option to prevent an issue of the adhoc mode?

Obviously not. 1) You can't have tcp sockets in adhoc mode 2) select/poll is implemented through epoll

[d3m3vilurr]

why do you think i ignore you. but nvm i dont want meanless conversation in here. if you want please send message in discord or email.

---

well, you right. our select and poll uses epoll and currently it's limitated with socket.

idk sceIoOpen with SCE_O_NOWAIT is callable and can it work with epoll. hm

[isage]

idk sceIoOpen with SCE_O_NOWAIT is callable and can it work with epoll. hm

no. sceIoOpen also isn't relevant. MsgPipes can be async. It just requires additional work to multiplex them with sockets in poll/select

[d3m3vilurr]

hey isage. do you have any idea or suggestions? or just share the side effects?

[isage]

Yes. Use async MsgPipes

[d3m3vilurr]

Yes. Use async MsgPipes

yep you make sense.

I'll add the FIXME tag of it.

[nikarh]

The reason I did not go with MsgPipes is that they would require a clever reimplementation of epoll/select, and the only solution I can think of would be a spin loop doing syscalls to check pipe state for each pipe fds, and a netEpoll call that instantly returns for all net fds. And I don't know how justified syscalls in a spin loop are for pipes in terms of performance.

As for ad-hoc mode - I never tested it with ad-hoc, but at least opening a socket on loopback works with wifi disabled and in airplane mode.