Wrt. to POSIX I wonder how close / “compatible” redox wants to be with Linux and POSIX.
Mainly how much of the “bad” parts it wants to implement for compatibly issues. In Linux (as well as POSIX) there are often multiple layers/revisions of a solution for a specific problem where newer ones tend to combat problems found with the previous ones, making the previous one kinda obsolete.
A example would be
poll -> select -> epoll(linux)/kqueue(FreeBSD/Mac) or
signal -> sigaction -> signalfd/sigwaitinfo.
Especially wrt. to signals not supporting
sigaction) probably would be fine as signal is not really compatible with multi-threading and is deprecated even in the POSIX standart (as far as I know, might be mistaken).
So I think it would be a good idea to start with designing the “state of the art” kind solutions like e.g. epoll/kqueue/something_else_but_kinda_similar and then add older combat functions if needed.
As a side note when someone designs a system like epoll/kqueue for redox it would be nice to be able to handle signals over it as the default way to handle singnals on redox. In Linux this is possible with signalfd+epoll, kqueue on the other hand has only limited singal handling capabilities, while it can tell you which signals happened since the last kqueue query it’s limited to exactly that, so you don’t have access to the siginfo_t struct which can be retrived when using sigwaitinfo. Btw. from the many ways to handle signals (singal/sigaction/sigwaitingo/sigwait/signalfd/sigtimedwait) the “best” i.e. least brittle and race-condition prone seems to be to:. Block/mask signals on all other threads, then have one thread for handling signals (unblock/mask them) in which you basically build a simple event loop with sigwaitinfo (which suspends the thread until a signal happens) and when you get a signal event you forward this information through some other mean (e.g. channels) to all other interested threads. Naturally handling of inter-thread signals might require a bit of different work, but “typical” signal handler are prone to all kind of race conditions. So it would be awesome if this can be just part of the standart asyncIO/event system as the “best” solution is already quite similar to it anyway. : Aka the solution mentioned abvoe. Note that there are probably other “best” solutions, e.g. building a similar event loop with signalfd+epoll. I’m much to used to use libraries which abstract this away to be certain in any way.
here is a article discussing why signalfd does not “solve” the problem with signals. It also does explain a “best” solution similar to what I mentioned above but with more details and proposes how something like signalfd could actually solve the problem if it would be made slightly different:
(btw. it is from the person behind rust’s MIO)