[Gc] GC_use_DllMain and main thread registration
hans.boehm at hp.com
Wed Oct 20 16:13:29 PDT 2010
This is somewhat at odds with the goal of using a single library version to support a range of applications. I'd like to move away from custom-built versions of the library. But I have to admit that I don't know of a better way to address this problem, so I guess it's the best we can do.
> -----Original Message-----
> From: gc-bounces at linux.hpl.hp.com [mailto:gc-bounces at linux.hpl.hp.com]
> On Behalf Of Ivan Maidanski
> Sent: Wednesday, October 20, 2010 12:21 PM
> To: Christian Gudrian
> Cc: gc at linux.hpl.hp.com
> Subject: Re: [Gc] GC_use_DllMain and main thread registration
> I think the alternative to call GC_use_DllMain() is to compile GC with
> some macro defined which defines GC_win32_dll_threads (as a macro) to
> TRUE (like I did on Darwin - see DARWIN_QUERY_TASK_THREADS macro). I'm
> going to add that macro for Win32 in a week.
> Wed, 20 Oct 2010 11:21:15 +0200 Christian Gudrian
> <christian at gudrian.org>:
> > Hello!
> > I just tried to use the collector with DllMain based thread
> > and found a catch during the startup phase of our program. Since I'm
> > using the collector as a replacement for the standard memory manager
> > first allocations occur before I even have the chance to call
> > GC_use_DllMain. Subsequently GC_thr_init registers the main thread in
> > the table that is used for non-DllMain based registration. Once
> > GC_use_DllMain has been called collection from the main thread fails
> > it cannot be found in the now relevant other thread table.
> > Is it safe to call GC_use_DllMain at the beginning of the collector's
> > DllMain function in case of a process attaching?
> > Christian
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc