On Tue, 2005-06-14 at 11:47 +0100, michael meeks wrote: > So, > > A bit more poking - and it turns out all the memprof thread stuff > assumes that 'getpid' returns something different for each thread ;-) of > course, with NPTL [ ie. any recent system ] that just isn't so. > > Using a __thread variable instead makes it really solid. > > I attach a new patch; Owen - who maintains this now ? - and/or can one > just commit such things that fix clear brokenness without overmuch > review ? :-) I'm certainly not maintaining memprof at the moment. If John Myers has a chance to review the patch, that would be great. 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. 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. Regards, Owen (I don't think adding adding random conditions to g_io_channel_add_watch is correct, from a glance at the patch. There's no way that a channel will suddenly start reporting G_IO_PRI unless you've coded that into the structure of your app. No way to get G_IO_NVAL unless you have a bug in your app. Etc.)
Attachment:
signature.asc
Description: This is a digitally signed message part