> On Mon, Jan 16, 2023 at 3:30 PM Daniel Colascione <dancol(a)dancol.org> wrote: > > This sounds great, but how is it going to get made? Someone has to do it. :-) I've been thinking about adding this mechanism for a few years, but haven't had time so far. I suppose the first step would be raising the subject on libc-alpha and LKML. Both places (especially the former) tend to be conservative, so it'd be prudent to settle in for a long debate. > And is the kernel amenable to this in the first place? I don't think anyone's asked. I don't see a reason (at least a reason based on the technical merits) for the kernel to be opposed, but the Linux world isn't known for the tight coordination between the kernel, libc, and managed runtimes that this mechanism would require. I'm more worried about libc, to be honest. The last time [1] I proposed improvements involving signal handling, libc-alpha's response was essentially "No, absolutely not, we're not going to touch a thing related to signals because nobody should be using signals for any purpose whatsoever". I don't think this is a terribly realistic perspective on the part of libc-alpha, especially given how often signals are, in fact, used productively in the real world. I hope that they might be a little more moderate when it came to unwinding. [1] https://sourceware.org/legacy-ml/libc-alpha/2018-03/msg00214.html _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
