About pthreadpool_tevent

[Matthieu Patou]

Hi Volker,
On 02/03/2017 12:39 AM, Volker Lendecke wrote:
> On Thu, Feb 02, 2017 at 11:34:34AM -0800, Matthieu Patou wrote:
>> All,
>>
>> So the pthreadpool_tevent in just under source3, is there a good reason
>> to keep it here ? Couldn't be move to lib at the root of repository ?
> As you asked about 4.5 also: Please use fncall_send in 4.5. 4.5 even
> has a getaddrinfo_send, which I removed for 4.6. It was unused and
> only a sample for 4.6, and it should be trivial to port to the 4.6
> functions.
>
> The reason for the pthreadpool_tevent merge is that we don't go
> through epoll with the new code. Epoll can't prioritize the signal
> pipe from the pthreadpool, so finished jobs can starve under high SMB
> traffic. This should not affect your case with DNS lookups though, so
> the 4.5 code should be fine for you.
>
I'm looking for a solution for 4.6+ as well as we want to avoid to have
to maintain too much patches for a long time.
So right now I'm trying the pthreadpool_tevent way. I haven't looked
very deeply at the implementation, only at your torture tests and the
use in vfs_default.c

If the structure is shared across threads is the API taking care of
locking/unlocking access to the memory ?
Quick glance seems to indicate that it's not but I wanted to confirm
this, or maybe you highly recommend to use non shared memory to avoid
issues.

Matthieu


-- 
Matthieu Patou
Samba Team
http://samba.org