Re: Question regarding life time of backend threads in PDNS

Seema Datar <[email protected]>
Newsgroups gmane.network.dns.powerdns.devel
Message-ID <CEB3A6C4.60C98%[email protected]>
Hi All,

I had a followup question. I am assuming there can be only one backend
instance per thread. Can you please confirm that? So, basically if there
are 8 threads of execution, can I assume that there are only 8 backend
instances running?

Thanks,
Seema

On 11/8/13 1:03 PM, "Aki Tuomi" <[email protected]> wrote:

>On Fri, Nov 08, 2013 at 07:22:40AM +0000, Seema Datar wrote:
>> Hi All,
>> 
>> Does anybody have more information on this?
>> 
>> Thanks,
>> Seema
>> 
>> Hi All,
>> 
>> We have a use case where we use PDNS with 8 backend threads. We needed
>>to save thread specific data in an mmap. However, I came across the
>>following in PDNS documentation -
>> 
>> PowerDNS may instantiate multiple instances of your backend, or destroy
>>existing copies and instantiate new ones. Backend code should therefore
>>be thread-safe with respect to its static data. Additionally, it is wise
>>if instantiation is a fast operation, with the possible exception of the
>>first construction.
>> 
>> The questions I had are -
>> 
>> 
>>   1.  What is the lifetime of a backend thread?
>>   2.  How often does a thread get destroyed and a new  thread get
>>created?
>>   3.  Is there any interface available to do a cleanup before the
>>thread ends?
>> 
>> Thanks,
>> Seema
>
>Lifetime of a backend thread is dependant on several factors, and the only
>thing you can assume is that it's not something you can rely on.
>
>The only thing backend module can use for cleanup is the destructror of
>the 
>backend class. 
>
>Or if you use remote/pipebackend, you can wire it to look for EOF or
>signal 
>and cleanup when either one is received before dying out.
>
>Aki Tuomi
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.