Milter-greylist

>  > >   
>  > > http://lists.freebsd.org/pipermail/freebsd-bugs/2005-January/0
>  > > 11028.html
>  > >  
>  > > That message contains a workaround.  If calls fclose() on
>  > > the FILE*, then immediately uses dup2() to re-allocate the
>  > > file descriptor low_fd.
>  > >  
>  > 
>  > It is not guaranteed in a multithreaded program working reliably.
> 
> Come on, multithreaded programming isn't voodoo magic.  :-)
> You can easily make the guarantee that there is no race
> condition by properly programming, e.g. using a semaphore
> or mutex.  If you're doing threaded programming, then you
> should very well know what you're doing anyway.
> 

You are absolutely right as any good politician giving generic statements. Please stay on the Earth.
I did not thought that I have to give more details, here it is:
If you want to use fclose(); dup2() sequence, you have to protect all the system calls in your program which leads to file descriptor allocation in all the threads. Otherwise the kernel will allocate this low file descriptor to other thread, if your current thread is pre-empted in the middle of this critical section.
For example you have to modify the libmilter blocking the execution of accept() on the milter socket while your dump thread is in the above sequence. Theoretically possible, practically impossible to implement.