Anonymous user
Talk:Run as a daemon or service: Difference between revisions
→A different angle
Line 65:
: I did not see anything in this task which was relevant to DOS TSRs.
: As far as I know, this approach (redefining stdout) is only relevant for "daemons" when you are running the program under Unix. --[[User:Rdm|Rdm]] 18:36, 17 November 2011 (UTC)
:: from a users perspective the process ends, but it is actually still there. the fact that DOS TSR requires an interrupt for the program to wake up has more to do with the lack of multitasking than being something different alltogether.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
: Current problems with the task:
: # It's difficult to say what constitutes a daemon. It should run in background in some sense, and preferrably do something useful; other than that anything goes. It may or may not hold on to a tty (getty vs sendmail); it may or may not be system wide (gnome launches a million per-user background processes upon user session start); it may or may not interact with direct user input (gpm, XIM daemon, etc). You need to narrow it down, or change the task to just focus on detaching from parent process.
:: hmm, all these should be fine. the daemon just shouldn't interact with the shell that it was started from.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
: # Backgrounding a process has more to do with OS than programming language. On unix you may let init adopt the process, on Windows you need to have user login script to start the process or use regsvc or svchost. It's also not clear if any of the systray icons count as a daemon.▼
: # Backgrounding a process has more to do with OS than programming language.
: # Redirecting stdio is useful to have the daemon not die unexpectly on hangup or something, but it's not a defining property. Also your requirement of redirecting is strange: the program is supposed to write to stdout; the program is not supposed to ''really'' write to stdout; the program is not supposed to worry about where the output goes; the program is not supposed to be invoked by shell redirection, so it must know where the output goes. Make up your mind, maybe? --[[User:Ledrug|Ledrug]] 00:10, 18 November 2011 (UTC)▼
:: but programming languages may well include support for this for different OSes so that the programmer does not have to deal with the details. or they may not. we might find out in the course of this task.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
▲:
:: they probably would if the program disconnects from the command shell it was started from. but i don't know how that actually works on windows. i'll probably find out at some point--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
: # Redirecting stdio is useful to have the daemon not die unexpectly on hangup or something, but it's not a defining property.
:: correct. it is a requirement specific to this task.--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
▲:
:: ok, this needs clearing up: the daemon should not write to the stdout that is connected to the terminal it was started from. it may write to stdout if that has been redirected to a file, by means that are either within the daemon itself or in a separate helper program written in the same language.
:: the part with not caring was supposed to refer to functions or libraries used within the daemon which constitute the useful part, not the daemonizing part. that is, it should be possible to take an existing program, and turn it into a daemon without having to replace all references of say <code>printf(...)</code> with <code>fprintf(somefile,...)</code>--[[User:EMBee|eMBee]] 09:10, 18 November 2011 (UTC)
| |||