On Thu, 2005-06-23 at 10:43 +0100, michael meeks wrote: > On Tue, 2005-06-14 at 11:33 -0400, Owen Taylor wrote: > > Otherwise, you can just go ahead and commit. Memprof hasn't been working > > in recent quick tests I've done even for single threaded apps, but I > > haven't had time to try and figure out why. I think it's libc changes, > > as usual. > > Interesting. > > > Using thread primitives in memprof is something that I've always been > > very wary of, because memprof is hooking in at the clone level *before* > > the new thread is fully established. But if the use of a per-thread > > variable works, I guess it works. > > So - just out of interest; why don't we hook the callback passed to > clone and then do our setup inside the new thread before handing control > to the child function ? The point is that we aren't hooking pthread_create(), we are hooking clone(), and libc itself will do additional setup inside the child function of clone() before calling the user's function to start the operation of the thread. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part