well the suckers are down to 260k each at startup (was 548k), so that's
promising.. trouble is that a SIGHUP (restart) causes the new children
to die when servicing any request :-(
So, how ugly is the following suggestion...
Rather than have the parent process attempt to cleanup after
a SIGHUP, it could do the following..
very early in the code (first line maybe),
while((pid=fork())) /* while it was you that called fork */
waitpid(pid, NULL, 0); /* wait for the child to exit */
/* child falls through */
Then a SIGHUP can be handled by writing "bye bye" to the error log,
followed by an exit(0);
It's a lot easier than using siglongjump and freeing loads of resources.
I just looked at the man page for siglongjmp; it's storing a pile of
info much like a 2nd process would anyway, but the man page also says
"But, because the register storage class is only
a hint to the C compiler,
variables declared as register variables may not necessarily
be assigned to machine registers, so their values are
unpredictable after a longjmp(). This is especially a prob-
lem for programmers trying to write machine-independent C
routines."
so my alternative might not be so bad after all.
It might also be worth ditching the children's longjump handling and
just let them exit whenever they would otherwise jump. N.B. they'll be
replaced with a new child almost immediately.
thoughts ?
--
Rob Hartill
http://nqcd.lanl.gov/~hartill/
promising.. trouble is that a SIGHUP (restart) causes the new children
to die when servicing any request :-(
So, how ugly is the following suggestion...
Rather than have the parent process attempt to cleanup after
a SIGHUP, it could do the following..
very early in the code (first line maybe),
while((pid=fork())) /* while it was you that called fork */
waitpid(pid, NULL, 0); /* wait for the child to exit */
/* child falls through */
Then a SIGHUP can be handled by writing "bye bye" to the error log,
followed by an exit(0);
It's a lot easier than using siglongjump and freeing loads of resources.
I just looked at the man page for siglongjmp; it's storing a pile of
info much like a 2nd process would anyway, but the man page also says
"But, because the register storage class is only
a hint to the C compiler,
variables declared as register variables may not necessarily
be assigned to machine registers, so their values are
unpredictable after a longjmp(). This is especially a prob-
lem for programmers trying to write machine-independent C
routines."
so my alternative might not be so bad after all.
It might also be worth ditching the children's longjump handling and
just let them exit whenever they would otherwise jump. N.B. they'll be
replaced with a new child almost immediately.
thoughts ?
--
Rob Hartill
http://nqcd.lanl.gov/~hartill/