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":"When `radicle_signals::handler` is called when a signal is\ndelivered and when it locks the mutex, it's possible that\none or more subsequent signals are delivered that also call\n`handler`, while the first call of `handler` still holds the\nmutex, which causes the subsequent call(s) to `handler` to\ntry to acquire the mutex but they can't and so they just do\nnothing and so no notification is sent on the\nsignals-notification channel.  This prevents the desired\nprocessing of such subsequent signals from being done.\nE.g. if SIGWINCH or SIGHUP is delivered and then SIGTERM or\nSIGINT is delivered immediately following while the handling\nof the first signal still holds the lock, the program will\nnot be shutdown, or the current TUI spinner or pager will\nnot be aborted, etc, as was desired.\n\nThis can more easily be reproduced in a debugger by keeping\nthe first call of `handler` stopped while it holds the lock\nand then sending subsequent signals.  This is sufficient to\nprove it could happen in production.\n\nThe mutex is only needed for installing & uninstalling the\n`static NOTIFY` channel.  It's not necessary for `handler`\nto access the channel, because `crossbeam_channel::Sender`\nis `Sync` and would work if accessed directly and\nconcurrently.  But wrapping it in a mutex forces the need to\nacquire the lock to access it.\n\nIt might be possible to instead use `std::sync::OnceLock`\nwhich would fix this issue by avoiding mutual exclusion in\nthe `handler`.  `OnceLock` is only available in Rust\nversions >= 1.70, and since the `rust-toolchain` file of the\nHeartwood repository uses 1.77, I'm guessing that the\nrequirement of at least 1.70 might be acceptable.\n\nBut using `OnceLock` (or anything that's not like a mutex)\nwould prevent being able to mutate the `static NOTIFY`,\nwhich would prevent being able to install a different\nchannel after one had already been initially installed and\nthen uninstalled.  I don't know if that use-case is needed,\nbut it's currently possible, and changing this might require\nredesigning the uses of `radical_signals` by `radical_term`\nif it needs that use-case.  I'd need to review\n`radical_term` more.\n\nUninstalling by itself would still be used the same, with\nhaving `OnceLock` instead, since the `uninstall` function\nwould still be able to do `libc::signal(..., libc::SIG_DFL)`\njust the same.  With the signals' handling reset so that\n`handler` isn't used anymore, it wouldn't matter that the\n`Sender` side of the channel is still held in the\n`static NOTIFY`.  The `Receiver` would still be dropped when\ndesired, which would still disconnect the channel.\n\nHowever, using `OnceLock` and a channel, or almost any other\napproach, would still not be async-signal-safe, as I\ndescribed in issue#111cf90.  Resolving that issue could also\nresolve this issue, so maybe it's not worth it to implement\na `OnceLock` (or whatever) approach that would not be kept.","type":"comment"}

1

@@ -0,0 +1 @@
+{"title":"signals: Mutex can cause signals to be missed","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}