On Wed, Feb 26, 2025 at 2:49 PM Nicholas Renner ***@***.***> wrote: Did some quick research on this and wanted to provide some answers to help this along. As far as syscalls we implement I think this is the list of calls that need to be interrupted by signals: - wait()/waitpid() - sleep()/nanosleep() etc - futex() - read()/write() - accept()/connect() - send()/recv() - poll()/select()/epoll_wait() *Checking in code:* For the wait() family as well as select/polling we never actually block in the kernel, so we can just insert a check in RustPOSIX if a signal is set and return with EINTR. This should be relatively easy. *Timeouts:* Both sockets (accept, connect, send, recv, read/write on sockets) and futexes implement options for a timeout. I think the easiest way to deal with these (and how we did it in rustposix) is to add a relatively short timeout (100 ms? we'll need to investigate whats optimal here) on all sockets/futexes we create and call the underlying syscall in a loop with a check in between calls until it returns something relevant. *Sleeps* We'll probably have to do something inventive here to make this return early. *Read/write* Since reads and writes can go to a number of subsystems, particularly pipes and sockets this is a bit tricky we'll need to discuss a more complex game plan here but is most likely a mix of timeouts and playing around with O_NONBLOCK. — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD4TWGO5HY3SRFILP6T2RYLF5AVCNFSM6AAAAABXY5IV6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBWGA2DCMBSGU> . You are receiving this because you commented.Message ID: ***@***.***> [image: rennergade]*rennergade* left a comment (Lind-Project/lind-wasm#118) <#118 (comment)> Did some quick research on this and wanted to provide some answers to help this along. As far as syscalls we implement I think this is the list of calls that need to be interrupted by signals: - wait()/waitpid() - sleep()/nanosleep() etc - futex() - read()/write() - accept()/connect() - send()/recv() - poll()/select()/epoll_wait() *Checking in code:* For the wait() family as well as select/polling we never actually block in the kernel, so we can just insert a check in RustPOSIX if a signal is set and return with EINTR. This should be relatively easy. *Timeouts:* Both sockets (accept, connect, send, recv, read/write on sockets) and futexes implement options for a timeout. I think the easiest way to deal with these (and how we did it in rustposix) is to add a relatively short timeout (100 ms? we'll need to investigate whats optimal here) on all sockets/futexes we create and call the underlying syscall in a loop with a check in between calls until it returns something relevant. *Sleeps* We'll probably have to do something inventive here to make this return early. *Read/write* Since reads and writes can go to a number of subsystems, particularly pipes and sockets this is a bit tricky we'll need to discuss a more complex game plan here but is most likely a mix of timeouts and playing around with O_NONBLOCK. — Reply to this email directly, view it on GitHub <#118 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGROD4TWGO5HY3SRFILP6T2RYLF5AVCNFSM6AAAAABXY5IV6WVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMOBWGA2DCMBSGU> . You are receiving this because you commented.Message ID: ***@***.***>