Talk:Background process

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Is the definition of background process here correct? If I run firefox as "firefox &", it's technically a background process even though it's not running with "minimal user interaction and minimal impact on the overall system". OhSqueezy (talk) 05:09, 3 November 2010 (UTC)[reply]

Interesting point, but I think it's actually not technically a background process precisely because it'll run in the "foreground" interacting with the user. Yes, you're using the shell's background process operator to ask for a new prompt, but all the Unix shells were defined before most users even had windowing displays and the terminology doesn't reflect the possibility of a new window opening for that "background process." Msnicki (talk) 05:20, 3 November 2010 (UTC)[reply]
I understand why calling Firefox a background process seems strange when it's on the screen giving output. However, it's not writing to standard output, which is what distinguishes it from a foreground process. I think to logically not call Firefox a background process in this context would require a redefinition of the manual. This reference clearly states that the ampersand operator indicates a process to be run in the background: http://www.linfo.org/ampersand.html OhSqueezy (talk) 01:34, 5 November 2010 (UTC)[reply]
Again, you're looking at a description of how a typical Unix shell works, describing how shells interpret the & operator at the end of a command and the terminology that's used in that context. But this is not a definition of a background process in the broader context of how operating systems works. Also, you're wrong about whether the process writing to stdout distinguishes foreground from background processes. If you start a command with an & at the end but don't redirect stdout and stderr, the shell terminology is to call that a background process but the output still comes to the screen, mixed in with any output from anything else. (Try it!) And by your definition that FF is a background app because it writes to the screen but doesn't use stdout makes no sense at all; I don't know where you'll find support for that position. Beyond that, I suspect I'll begin to repeat. Perhaps others may join in to offer their remarks; it's obvious you don't find me convincing but maybe you'll believe someone else. Msnicki (talk) 02:54, 5 November 2010 (UTC)[reply]
OK, after some research, I agree that whether or not the process writes to standard output isn't a verifiable way to distinguish. Here is a source w/ a definition of background process: http://www.gnu.org/software/bash/manual/bashref.html ("Background processes are those whose process group id differs from the terminal's; such processes are immune to keyboard-generated signals.") Yes, this source is also specific to the Unix shell, but shouldn't the article have information like this? If not, and it should be about the general perception of background process, then why not redirect to daemon? I'm just trying to help by pointing out some references to background process, which the page says it needs. OhSqueezy (talk) 04:59, 5 November 2010 (UTC)[reply]
And I concede that you have a point that the term has another use in the context of how Unix shells work. If you'd like to try your hand at reworking the article to explain those two different meanings, go for it. Be bold. Msnicki (talk) 05:29, 5 November 2010 (UTC)[reply]
OK, thank you for the replies. I'll have a go at it after work and this weekend. OhSqueezy (talk) 07:17, 5 November 2010 (UTC)[reply]
OhSqueezy, your edits don't match what I thought we'd agreed, which was there is a second, less significant meaning to word background process in the context of a shell. The rewrite you've done focuses on primarily on that secondary meaning. I think this should be reverted. Msnicki (talk) 14:07, 10 November 2010 (UTC)[reply]
How could you do that? You must have been aware of the work I put into that revision. Nearly all the previous content was included, just reworded. All the research I've done indicates that is the primary definition of background process. When I search for the concept of background process on other OSes, I get links to how to start a "unix-like" background process. Daemon is a subset of that definition. Somebody who is searching for an explanation of the term background process is better served by my revision, which is fully cited, while the current revision has no citations. OhSqueezy (talk) 23:40, 10 November 2010 (UTC)[reply]

OhSqueezy's rewrite[edit]

I'm not comfortable with OhSqueezy's rewrite, both because I think it's too Unix shell-centric, burying the generality of background processes beyond just Unix, and because I think it should have been possible to negotiate something acceptable here on the talk page. I'm even less comfortable reverting again both because an edit war never serves any purpose and because I concede I may be too close to the issue.

So I'm going to back off. But I do note that every other editor who's worked on this page seems to have been in agreement, judging by their contributions, with the view that it's not just about Unix shells. So maybe one of you has a comment. As I said, I'm backing off. Msnicki (talk) 06:49, 12 November 2010 (UTC)[reply]

"Background process" vs. "job"[edit]

Are "Background process" and "job" synonymous? Or is there a difference? --Abdull (talk) 19:47, 22 August 2012 (UTC)[reply]

Current state of this page[edit]

It looks like this page has barely been touched since the Windows Vista era. Additionally, it seems unnecessarily technical in some places, reading almost like a technical write-up in some ways. I'm not nearly expert enough to rewrite or majorly update the page, but I'd urge anybody who is to take a look at it. The9thBit (talk) 07:02, 30 April 2020 (UTC)[reply]