Re: memprof + threads fix ...

[michael meeks <michael meeks novell com>]

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 ?

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

	Ah ;-) and I like the random conditions :-)

	Thanks,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot