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. > 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 > 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. BTW: I'm currently packing to move house, so don't expect much feedback until late next week, or early the week after :[. Rob -- --- GPG key available at: http://users.bigpond.net.au/robertc/keys.txt. ---
signature.asc
Description: This is a digitally signed message part