[HN Gopher] The evolving Unix attitudes on handling signals in y... ___________________________________________________________________ The evolving Unix attitudes on handling signals in your code Author : ingve Score : 36 points Date : 2023-07-03 06:28 UTC (16 hours ago) (HTM) web link (utcc.utoronto.ca) (TXT) w3m dump (utcc.utoronto.ca) | skissane wrote: | POSIX could make everyone's life easier if there was a standard | facility to make signals run on dedicated "signal handling | threads". If my SIGINT handler has its own thread that only ever | runs that handler (and never runs it re-enterantly), most of | these safety issues go away. It is possible to implement that | now, but it would be a lot easier if it were just a feature of | the C library-and unlike other solutions like the self-pipe | trick, the coding model is essentially unchanged (no assumption | the program has an event loop). That doesn't really work for | inherently thread-specific signals such as SIGSEGV, but far fewer | people are interested in handling those | hulitu wrote: | > The evolving Unix attitudes on handling signals in your code | | The evolving "Unix attitudes" became non Unix. Bloat is | everywhere in Linux. | sophacles wrote: | What do you mean by bloat? I find each person has a different | definition. Can you also provide some examples? | NoZebra120vClip wrote: | > The evolving "Unix attitudes" became non Unix. Bloat is | everywhere in Linux. | | I'm not sure what you mean. The point of the article is to | explain that older implementations played fast and loose with | signal handlers that might do all sorts of operations that | turned out to be unsafe. As Chris points out, the current POSIX | standard is very constrained! You call some specific functions, | you set a flag, you GTFO. | | So I don't know what you are on about regarding bloat, because | if anything in Unix has slimmed down since V7, it's signal | handlers (see also the discussion about Bourne shell exploiting | SIGSEGV to allocate memory.) ___________________________________________________________________ (page generated 2023-07-03 23:00 UTC)