Daemon News Ezine BSD News BSD Mall BSD Support Forum BSD Advocacy BSD Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Changes from 5.2.1 to 5.3 (theads / signal handling)

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
David R. Butenhof

Thanks, I have it. I read it long time ago...