Changes from 5.2.1 to 5.3 (theads / signal handling)

[Julian Elischer]

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...
>
>
>