Create issue

Rad-Resource: 0f44f78b78

0

@@ -1 +1 @@
-{"blob":"1215c2a590644a5cf475a930c9544d6bd8b22844","description":"These are the keys of @fintohaps and @cloudhead's laptop key.","parent":"60ab40d9f4116c8ea5dcb81ac78c48fb69b5268e","signature":"z2YFFQ2xHTddV7EeWKymNDo8PbLCqpuGW3Q4vx3GMscHepcLedMKvfURyCkS7mCUt9ERe17mX79q15GtyezpMEDzB","title":"Add two more delegates","type":"revision"}
+{"body":"As [POSIX says][1]:\n> The `sigaction()` function provides a more reliable\n> mechanism for controlling signals; new applications should\n> use `sigaction()` rather than `signal()`.\n\nThe C standard (C17 7.14.1.1.7) says:\n> Use of this function in a multi-threaded program results\n> in undefined behavior.\n\nThe [`signal(2)`][2] man page of Linux also warns against\nusing it and says to use `sigaction()` instead.  Noteworthy\npoints from that say:\n> The only portable use of `signal()` is to set a signal's\n> disposition to `SIG_DFL` or `SIG_IGN`.  The semantics when\n> using `signal()` to establish a signal handler vary across\n> systems (and POSIX.1 explicitly permits this variation);\n> **do not use it for this purpose**.\n>\n> The effects of `signal()` in a multithreaded process are\n> unspecified.\n\nWhile `sigaction()` is limited to POSIX, but `signal()` is\nin standard C and so available in every OS, I assume that\nWindows is the only non-POSIX OS that Radicle might intend\nto support (for some time into the future).  Since Windows\nsimply does not have asynchronously-generated signals\n(IIUC), and because the Heartwood codebase does not (and\nshould continue to not) use `libc::raise` nor `libc::abort`,\nthere is no need to install any signal handlers when on\nWindows.  While the Rust `std` library does use\n`libc::abort` internally, that will still work as expected\non Windows, because Heartwood doesn't (and shouldn't)\ninstall a signal handler for `SIGABRT`.  So, `sigaction()`\nwill work for all supported OSs where signal handling is\nneeded.\n\nIf/when supporting other OSs requires having support for\nsome sort of analogue to POSIX signals, for Radicle to\nprovide the same functionality, it already would be\nnecessary anyway to have conditional compilation\n(`#[cfg(...)]`) to implement that separately from the\nPOSIX-signals approach.  I.e. the use of POSIX-only\n`sigaction()` doesn't affect this.\n\nWith using [`sigaction()`][3], it'll need to be decided what\nto give for `sa_mask` & `sa_flags`.  This will depend on\nwhat `radicle_signals::handler` needs to do and how it wants\nto do that, which I've suggested (in other issues I've\nopened) should be changed and decided on.  But probably,\n`sa_mask` should just mask all signals, and `sa_flags` won't\nneed `SA_SIGINFO` unless and until `radicle_signals` has\nmore involved needs in the future.\n\nWhether `SA_RESTART` should be used (given in `sa_flags`) is\nprobably the biggest question.  I think I prefer to use it,\nespecially with projects where there's a possibility that\nsome part(s), among all the transitive dependencies, forgot\nto handle `EINTR` (which isn't uncommon).  But `SA_RESTART`\ncan cause timeouts to be significantly longer than\nrequested, when restarting an interrupted function (usually\na syscall) that took a timeout.  This decision should be\nmade by someone much more familiar with the Radicle\ncodebases.\n\nNote that all of these questions about how to use\n`sigaction()` also apply to using `signal()`, but you just\nhave no control over nor consistency of them with\n`signal()`.  E.g. BSD `signal()` enables `SA_RESTART`; but\nLinux without `_BSD_SOURCE` nor `_DEFAULT_SOURCE` does not\nenable `SA_RESTART` but enables `SA_RESETHAND | SA_NODEFER`\nwhich is usually undesirable; but Glibc on Linux usually is\nlike BSD because `_DEFAULT_SOURCE` is defined by default;\nand Solaris man pages don't say what its `signal()` does\nregarding `SA_RESTART`.  Further, the behaviors of\n`signal()` w.r.t. masking and disposition-resetting are also\ninconsistent between POSIX OSs.  Given that C-preprocessor\ndefines can affect this mess, I don't know what the `libc`\nRust crate does on different OSs regarding which semantics\n`libc::signal` has for these aspects.\n\nUsing `libc::sigaction` instead will give consistent\nsemantics across OSs and guarantee support for\nmulti-threaded programs.\n\n[1]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/signal.html#tag_16_550_07\n[2]: https://www.man7.org/linux/man-pages/man2/signal.2.html\n[3]: https://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html","type":"comment"}

1

@@ -0,0 +1 @@
+{"title":"signals: `libc::signal` should not be used","type":"edit"}

embeds/radicle.json

@@ -1 +0,0 @@
-{"delegates":["did:key:z6MksFqXN3Yhqk8pTJdUGLwATkRfQvwZXPqR2qMEhbS9wzpT","did:key:z6MktaNvN1KVFMkSRAiN4qK5yvX1zuEEaseeX5sffhzPZRZW","did:key:z6MkireRatUThvd3qzfKht1S44wpm4FEWSSa4PRMTSQZ3voM"],"payload":{"xyz.radicle.project":{"defaultBranch":"master","description":"Radicle Heartwood Protocol & Stack","name":"heartwood"}},"threshold":1}

manifest

@@ -1 +1 @@
-{"typeName":"xyz.radicle.id","version":1}
+{"typeName":"xyz.radicle.issue","version":1}