Jose Marcio Martins da Cruz wrote:
Julian Elischer wrote:
Jose Marcio Martins da Cruz wrote:
So, if I understood, the better I can do is, instead of letting the
child follow
a different path after the fork, he shall better do an exec of
another thing and
start a clean process...
often what is done is to exec itself again with a different argument
to make it know it is the child.
why do you need to fork? why not just use more threads?
This is a security issue. The application is a sendmail mail filter.
For many reasons the filter may die : an attack may succeed or there
may be a bug.
The father is a supervisor only. He launches the child which is the
real filter. From time to time, the father checks if the filter is
alive and running (not blocked) - this is done by a non blocking wait
and a pipe between the father and the child. If there is a problem
with the child (died of blocked), the father does some clean up and
launches a fresh child.
sounds like the parent need not be threaded yet.
I use a different process instead of more threads because a problem
with a thread can compromise all the process.
This application runs fine under Solaris (four years long now).
Each implementation has different side-effects
On FreeBSD 6, try the libthr() threading library.
Well, I definitely shall try to change this architecture, at least for
FreeBSD and maybe Linux too.
I can suggest the threads programming book
Programming with POSIX Threads
by
David R. Butenhof
Thanks, I have it. I read it long time ago...
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
