[PATCH] Patch for MTinterface

Thomas Pfaff tpfaff@gmx.net
Tue Nov 5 05:52:00 GMT 2002

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).


More information about the Cygwin-patches mailing list