Re: Persistent connections



On Jul 29, 5:18 pm, The Natural Philosopher <t...@xxxxxxxxxxxxxxx>
wrote:
Joseph wrote:

  how: do you get a persistent PHP

process running, without having to launch it from a local HTTP client.
CRON means that it is going to execute on regular basis, and I do not
want this. I want it to run only once. So, the at command (from an SSH
terminal session) may be a solution: at -f sample.php now (though the
f is redundant), but that does not seem to be working.

That's because (unless you have a very unusual non-posix compliant
version of 'at') -f specifies a file to be read for the commands to be
run - NOT the command itself. Try 'man at' at the command line.


Simply open it using a command line php, with & after it to place it in
background, and hope that exiting the shell doesn't nerf it. It should
not.,

Yes it should.

A HUP sent to (or a exit called from) the parent process will send a
HUP to all child process. While you could write a signal handler in
the child process to ignore the HUP (or start with nohup which does
the same thing). However this is a particularly messy solution as the
child process becomes orphaned - and how it behaves after that will
vary depending on the underlying OS and subsequent events - certainly
this is the route to zombie processes and deadlocks.

The correct way on POSIX to start a process which is intended to last
longer than the process which created it is to reassign the session
header to that of init (which never exits while the system is running
- OK that's not quite true, but will do as an explanation for now). A
pre-requisite of that is to dissociate the stdin, stdout and stderr
streams from the parent pty before calling setsid().

Really you can never have a process which runs after its parent has
expired - the method described above just changes the parent process
to init - and as per my previous post you can easily hang the task off
any long running process ('at' in my previous post).



is the sort of command. I couldn't swear to the exact syntax.

I dont like scripts running as daemons though. I'd personally write a
proper forking daemon in C...;-)

It's not a problem as long as your careful about the memory
management. Right now, I'm not sure how much impact this can have
using purely procedural code (there may be a problem with dynamic
arrays - but I'e not been able to establish conlusively one way or
tother yet) but with Object Oriented code, you're going to run into
problems quite quickly unless you have the circular reference checking
garbage collector running.

C.
.