Talk:Signal (IPC)

Link dead

Link 13 is dead. 2003:C7:4F29:8A05:4ECC:6AFF:FE93:1F63 (talk) 12:40, 16 September 2020 (UTC)

Untitled

"A process's execution may result in the generation of a hardware exception, for instance, if the process attempts to divide by zero or incurs a TLB miss." Which architectures generate an exception on a TLB miss? x86 and x86_64 CPUs certainly don't (note: page fault != TLB miss). —Preceding unsigned comment added by 147.188.254.195 (talk) 12:00, 14 October 2010 (UTC)

MIPS 1. Bomazi (talk) 00:56, 18 March 2012 (UTC)

Merging individual signal pages

Currently there are quite a lot of pages created for single signal. Most of them are very short, have very little encyclopedic potential and contain duplicate material. I propose to merge them to this article, since it already contains a signal comparison table. Notable signals could have a separate section added, though I doubt this would be needed because most of the content already fails WP:NOTMANUAL.

The pages in question: SIGABRT, SIGALRM, SIGFPE, SIGHUP, SIGILL, SIGINT, SIGKILL, SIGPIPE, SIGQUIT, SIGSEGV, SIGTERM, SIGUSR1 and SIGUSR2, SIGUSR1 and SIGUSR2, SIGCHLD, SIGCONT, SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU, SIGBUS, SIGPOLL, SIGPROF, SIGSYS, SIGTRAP, SIGURG, SIGVTALRM, SIGXCPU, SIGXFSZ, SIGRTMIN and SIGRTMAX, SIGEMT, SIGSTKFLT, SIGINFO, SIGPWR, SIGLOST, SIGWINCH, SIGUNUSED

1exec1 (talk) 14:08, 10 January 2012 (UTC)

Oppose - this is not a merge proposal, its a redirect proposal, especially your last sentence I doubt this would be needed because most of the content already fails WP:NOTMANUAL.

No, I didn't say all content, I said most. There is definitely a lot of information that should be retained, I just think that except for several cases, it either is almost duplicate across different articles (e.g. etymology section), or can be represented in a table. I can do the merge by copy-pasting all signal pages to the target article under separate sections and then doing the cleanup. So this is not a redirect proposal, since the cleanup will be done separately using the usual BRD cycle. 1exec1 (talk) 11:24, 12 January 2012 (UTC)

Oppose

It's useful that this page act as a category for each signal -- the details and contexts of which vary. I don't think the formatting consistency of individual signal pages is a strike against it ("almost duplicate across different articles"). And I'm not sure what "(they) have very little encyclopedic potential" means. 98.245.10.124 (talk) 23:40, 14 January 2012 (UTC)

Oppose - Unix (&&derivatives) is important enough to justify detailed information and the way it’s arranged now provides good clarity. 79.230.172.139 (talk) 14:55, 15 January 2012 (UTC)

Oppose - There are details like the Number of the signals that could be different on Unix-Like systems, and this will requre a huge table with all of them on a central page for better understanding. And making such a lot of redirects is not a good approach Risthel (talk) 00:01, 8 February 2012 (UTC)

Oppose - We need smaller and easier articles and each signal has enough interest for us to write an article. Hashar (talk) 18:54, 12 April 2012 (UTC)

Oppose - Detailed information about each signal warrants individual pages. Merging them into one page will increase the size dramatically, and reduce the findability and availability of said information. --DanielRenfro (talk) 15:53, 25 April 2012 (UTC)

Oppose - This being a generic page on signals, each implementation may require as separate page to avoid clutter in this page. Leningrad (talk) 09:09, 14 May 2012 (UTC)

There are pessimists about this idea 'all signals merged'. I'm among them. In now, I just need to read about one particular signal, not all of them, and I do it in more easy way how is it in now. Merging make huge articles. May be brief articles in resume stile what compress inside tremendous volume of useful information is best way to describe my perception for best information delivery tool. — Preceding unsigned comment added by 46.10.229.1 (talk) 23:25, 17 June 2012 (UTC)

Oppose - I think this proposal is misguided for two reasons. Firstly, it is difficult to see how signal pages could be merged in without producing either clutter (in the form of extended explanations tacked onto a concise table) or inconsistencies (where some signals have links to pages but others do not). The second reason is that this is not actual manual material in the sense WP:NOTMANUAL proscribes. Whilst this material might appear in a reference manual, it is not a description of how to achieve something. If we start rooting out reference material from Wikipedia, where do we stop? 194.60.90.1 (talk) 08:58, 9 July 2012 (UTC)

Oppose - It's okay for there to be short articles, and if the individual signals all got merged into Unix Signal that would end up being very long. There are several ways to move between the pages, such as the Computing Signals template, the "List of Signals" table in this article, and the wikilink to Unix Signal from each individual signal article. This means that each reader can choose to read about a particular signal or get an overview of Unix signals in general, depending on his or her particular need. 138.16.160.4 (talk) 20:02, 10 July 2012 (UTC)

Support. Most of these articles are unreferenced, and I doubt that any existing sources elaborate very much on these signals; most probably just list them all together, or mention them while discussing their respective uses, about which there is pretty little to say, not counting what would violate WP:NOT. I claim this makes most of them fail WP:N (if not all). A standalone list article would be acceptable, though. Keφr (talk) 16:12, 26 July 2012 (UTC)

Merging the individual signal pages: 2nd try

The comments opposing the merging in the above proposal haven't addressed my main concern about violations of Wikipedia guidelines WP:OR, WP:N and WP:NOT. A second discussion was started here, it seems that the consensus for the merge is unanimous. 1exec1 (talk) 15:02, 6 October 2012 (UTC)

SIGWINCH became a POSIX signal in Oct 2017

SIGWINCH became a POSIX signal in Oct 2017:

0001151: Introduce new signal SIGWINCH and functions tcsetsize(), tcgetsize() to get/set terminal window size

2601:14A:600:6420:F128:9801:9970:9A2A (talk) 11:49, 12 October 2017 (UTC)

Relationship between signal and interrupt

I placed a citation needed tag on this claim: Signals are similar to interrupts, the difference being that interrupts are mediated by the CPU and handled by the kernel while signals are mediated by the kernel (possibly via system calls) and handled by individual processes. A source is necessary because both the claim and the reasoning are vague . My research indicates that signals are the UNIX implementation of interrupts, not just similar to interrupts. For example, the textbook The Design of the UNIX Operating System by Bach (1986; pages 200-201) classifies signals into 7 categories. The categories are when a process finishes normally, when a process has an error exception, when a process runs out of a system resource, when a process executes an illegal instruction, when a process sets an alarm event, when a process is aborted from the keyboard, and when a process has tracing alerts for debugging. Every category generates an interrupt. Timhowardriley (talk) 20:28, 10 May 2022 (UTC)

India Education Program course assignment

This article was the subject of an educational assignment supported by Wikipedia Ambassadors through the India Education Program.

The above message was substituted from {{IEP assignment}} by PrimeBOT (talk) on 19:58, 1 February 2023 (UTC)