Implemented non-blocking pipe and socketpair #101
Conversation
| if (bind(listener, (struct sockaddr*)&server_addr, addr_len) == -1) { | ||
| close(listener); | ||
| return -1; | ||
| } | ||
|
|
||
| if (listen(listener, 1) == -1) { | ||
| close(listener); | ||
| return -1; | ||
| } | ||
|
|
||
| if (getsockname(listener, (struct sockaddr *)&server_addr, &addr_len) == -1) { | ||
| close(listener); | ||
| return -1; | ||
| } | ||
|
|
||
| if ((sockfds[1] = socket(AF_INET, type, protocol)) == -1) { | ||
| close(listener); | ||
| return -1; | ||
| } | ||
|
|
||
| if (connect(sockfds[1], (struct sockaddr*)&server_addr, addr_len) == -1) { | ||
| close(sockfds[1]); | ||
| close(listener); | ||
| return -1; | ||
| } | ||
|
|
||
| if ((sockfds[0] = accept(listener, (struct sockaddr*)&server_addr, &addr_len)) == -1) { | ||
| close(sockfds[1]); | ||
| close(listener); | ||
| return -1; | ||
| } |
There was a problem hiding this comment.
Since this impl delegates to other newlib methods (connect, accept, socket), they already set errno, so this shouldn't be a problem
|
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. |
|
If this is only for Tokio, maybe it's better to implement kqueue/epoll instead? |
Added socketpair and pipe2 for Vita target As an effort to port `tokio` to Vita, `socketpair` and `pipe2` calls were implemented in Vita newlib. A PR to newlib with these methods while limitations/implementation details are discussed (vitasdk/newlib/pull/101), but until it is merged there is [vita-newlib-shims](https://crates.io/crates/vita-newlib-shims) crate with these methods implemented. The implementation may change but methods will certainly remain, and the interface will remain POSIX. `socketpair` will be needed for `rust-lang/rust` std, `rust-lang/socket2`, `rust-lang/mio`. `pipe2` will be required for `mio` pipe-based Waker.
|
You
Obviously not. 1) You can't have tcp sockets in adhoc mode |
|
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 |
no. sceIoOpen also isn't relevant. MsgPipes can be async. It just requires additional work to multiplex them with sockets in poll/select |
|
hey isage. do you have any idea or suggestions? or just share the side effects? |
|
Yes. Use async MsgPipes |
yep you make sense. I'll add the FIXME tag of it. |
|
The reason I did not go with MsgPipes is that they would require a clever reimplementation of 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. |
Motivation:
In Rust ecosystem many libraries rely on a
tokioasync runtime, which internally requires nonblocking unix pipes (as a fallback for os'es without epoll or kqueue).This PR contains:
socketpaircall. This just creates a IPV4 socket pair yolo ignoring the domain passed as an argument since usuallysocketpairis used withAF_UNIX, and they are not supportedpipe2call for nonblocking unix pipes. Depending on the options it delegates either to the originalpipeor tosockerpaircall. This allows havingselect,poll,read,writecalls for nonblocking pipes without any additional code, because pipe in that case is just a pair of sockets.fcntlis not implemented, since I don't want to touch/break the originalpipeimplementation in case blocking pipes are needed.readandwritecalls for pipes, previously they returned buffer length instead of actually read bytes length