I have read that none of the samba code has been written to explicitly support threads, but that there are "sections" are not inherently thread-unsafe (e.g. talloc). I am attempting to write a multi-threaded client to interface with a MS RPC server (more specifically read the MS Event Log). My goal (and reasoning behind threads vs processes) is that I would like to establish a connection once, and then have a "random" worker operate on that connection. I considered a multi-process solution, but between sharing the connection and all the talloc'd memory needed to call the dcerpc_ functions, it seemed that it is worth trying to multi-thread the application. So my question, in short, is whether any of the dcerpc/tevent/talloc libraries are thread-unsafe? If not, do I need to do something special? In my testing thus far (with only 2 threads), I often, but not always, get a failure from 'dcerpc_pipe_connect_b' with error code 0xc000008b or?0xc000000d. Needless to say, I haven't seen a failure when removing either of the threads. Thanks, Ilya
On Mon, Jul 08, 2013 at 11:12:04AM -0700, Ilya Markov wrote:> I have read that none of the samba code has been written to explicitly support threads, but that there are "sections" are not inherently thread-unsafe (e.g. talloc). > > I am attempting to write a multi-threaded client to interface with a MS RPC server (more specifically read the MS Event Log). My goal (and reasoning behind threads vs processes) is that I would like to establish a connection once, and then have a "random" worker operate on that connection. I considered a multi-process solution, but between sharing the connection and all the talloc'd memory needed to call the dcerpc_ functions, it seemed that it is worth trying to multi-thread the application. > > So my question, in short, is whether any of the dcerpc/tevent/talloc libraries are thread-unsafe? If not, do I need to do something special?All these libraries are thread unsafe (although talloc with thread-specific contexts and avoiding the null context is thread-safe I believe - but that's not how it's used in the other libraries that call it). Wrap usage of them in mutexes. Jeremy.