On Tue, 5 Nov 2002, Robert Collins wrote:
> On Wed, 2002-11-06 at 00:14, Thomas Pfaff wrote: > > > > I have discovered some problems with the current MTinterface > > implementation. Here are 2 test cases: > > > Even if the handles would be valid the pthread_join call would try to > > delete a thread object that is created static which would result in a > > corrupted heap. > > Ouch. Good catch. > > > 2: fork related > > > The forked child will not get the same thread handle as its parent, it > > will get the thread handle from the main thread instead. The child will > > not terminate because the threadcount is still 2 after the fork (it is > > set to 1 in MTinterface::Init and then set back to 2 after the childs > > memory gets overwritten by the parent). > > For memory that should not be copied, mark it with NO_COPY in the > declaration. MTinterface is set thusly IIRC. dcrt0.cc:72:MTinterface _mtinterf; If the MTinterface would be NO_COPY than all fixup_after_fork calls would not work. > > > And i do not agree with the the current pthread_self code where the > > threadcount is incremented if a new thread handle has been created but > > never gets decremented (i do not expect that threads that are not created > > by pthread_created will terminate via pthread_exit). And the newly created > > object never gets freed. > > The dllinit routine will take care of this when we get that implemented > again. I don't I agree with Chris that calling code that might block on a mutex on thread detach would lead to a deadlock situation. Since you have no control what code will run in key desctructor functions i better would not run the destructors on thread detach (which would happen if you call pthread_exit on thread detach). > > > To avoid these errors i have made changes that will create the mainthread > > object dynamic and store the reents and thread self pointer via fork safe > > keys. > > Overall this looks good. What happens to non-cygwinapi created threads > now though? You mention you don't agree with the code, but I can't see > (from a brief look) how you correct it. They will get a pthreadNull object in the pthread_self call. No memory leaks, no lost handles and of course no chance to call any pthread function (But since the are not created via pthread_create i do no not expect that they make a call other than pthread_testcancel). Thomas