Re: [boost] [Thread] Looking for co-maintainers

Subject: Re: [boost] [Thread] Looking for co-maintainers
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-07 05:40:06

On Friday 06 December 2013 22:18:09 Vicente J. Botet Escriba wrote:
> Le 06/12/13 21:52, Andrey Semashev a écrit :
> > On Fri, Dec 6, 2013 at 10:34 PM, Vicente J. Botet Escriba
> 
> How about providing some patch for some of the older issues that I have
> not reached to solve? issues with dynamic libraries/tss.

I have implemented the alternative TLS in Boost.Sync. I don't know if it has 
the same issues with Boost.Thread has, but I took most of the low level code 
for hooking at thread termination from Boost.Thread, so it's likely it has the 
same problems.

I've taken a look at the Trac tickets and only found these two issues:

https://svn.boost.org/trac/boost/ticket/4833

Thread termination hooks don't work with MinGW when Boost.Thread is linked 
statically. I don't have enough knowledge about MinGW internals to propose a 
solution. Maybe this configuration should simply be declared of limited 
support.

https://svn.boost.org/trac/boost/ticket/3926

If I understood it correctly, the problem is that pthread_key_t cleanup 
function is registered from a dlopened .so, which is then unloaded while the 
thread that initialized the key is still running. I think, Boost.Sync is also 
susceptible for this. I'll try to find a solution, and if I find one, I'll 
prepare a patch for Boost.Thread. Or maybe Boost.Thread could be just ported 
to Boost.Sync TLS? As far as I can tell, it should be a drop-in replacement.

Are there any other issues you're aware of?

> I'm not requesting help on new features or refactoring, but on solving
> the current and future issues. If you want to port Boost.Thread to
> Boost.Synch I think the best is to create a Boost.Thread2 so that you
> would not have the compatibility constraint Boost.Thread has now. I
> think that you have already a good base on Boost.Sync.

Ok, so it'll be Boost.Async then, as someone suggested earlier. :) I just 
thought it would be wiser not to spread our efforts between Boost.Thread and 
Boost.Async and just have one library. The backward compatibility issue could 
be tackled with a suitable deprecation period for the old features.