Changes from 5.2.1 to 5.3 (theads / signal handling)
julian at elischer.org
Thu Jan 26 12:43:10 PST 2006
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...
More information about the freebsd-threads