[Gc] Win32 thread support
hans.boehm at hp.com
Wed Mar 30 11:40:52 PST 2005
Is there a way to do that without relying on third-party
My impression is that in the end this requires overwriting
of binaries (rewriting code in the process or binary rewriting
of executables) in some form? That would worry me, unless it
was supported directly by Microsoft.
> -----Original Message-----
> From: Thong Nguyen [mailto:tum at veridicus.com]
> Sent: Tuesday, March 29, 2005 4:51 PM
> To: Boehm, Hans; 'Ben Hutchings'; gc at napali.hpl.hp.com
> Subject: RE: [Gc] Win32 thread support
> Have you considered api-hooking the CreateThread API?
> > -----Original Message-----
> > From: gc-bounces at napali.hpl.hp.com
> > [mailto:gc-bounces at napali.hpl.hp.com]
> > On Behalf Of Boehm, Hans
> > Sent: Wednesday, 30 March 2005 11:44 a.m.
> > To: Ben Hutchings; gc at napali.hpl.hp.com
> > Cc: Boehm, Hans
> > Subject: [Gc] Win32 thread support
> > I'm looking at the win32 threading code in the gc7 tree again.
> > Basically this code is really ugly due to DllMain semantics.
> > Unfortunately, the DllMain manual entry doesn't seem to
> have improved
> > as much as I had hoped. Are there any win32 experts who know
> > if the _DETACH calls are guaranteed to be made
> > in an ordinary thread context, and can thus lock?
> > It looks like there is no sane reason for that not to be the
> > case (unlike the _ATTACH calls). But the documentation
> > seems a bit contradictory on this particular point.
> > I'm actually a bit torn as to which direction this code
> should take.
> > The code currently sort of supports many different ways for
> > the collector of new threads:
> > - Preprocessor based CreateThread interception.
> > - Preprocessor based pthread_create interception. (Cygwin)
> > - Explicit registration calls (new in my tree).
> > - Registration through DllMain callbacks. Requires the GC
> > to be in a separate dll.
> > (The Linux pthread code also somewhat supports linker-based
> > interception, and I want to improve that support. That seems
> > infeasible here. Conversely, there is nothing like DllMain
> in Linux.)
> > The DllMain code complicates things immensely, since we
> > have to be able to register threads without acquiring a
> lock. But the
> > rest of the collector is designed to use locks, at least for
> > operations like thread creation. I think it has also lead
> to many bugs
> > in the code, especially when combined with other
> techniques. And it
> > has so far required a hard limit on the number of threads, not to
> > mention a performance cost with large numbers of threads.
> > I can think of several options:
> > 1) Default: Continue along the current path. If we can't
> lock in the
> > _DETACH path in DllMain, this may be impractical. In any case, it
> > looks more and more like a mess.
> > 2) Split this into two different win32 thread support
> layers, one that
> > relies on explicit interception of thread calls, and one
> the relies on
> > the DllMain hack. The former could work a lot more like
> the pthreads
> > version. This seems cleaner to me. It does mean that you need to
> > compile differently for different thread registration methods.
> > 3) Drop the DllMain support entirely. I suspect this is dubious
> > because people are relying on it. But I'm not sure.
> > I'm leaning towards (2). Opinions?
> > Hans
> > _______________________________________________
> > Gc mailing list
> > Gc at linux.hpl.hp.com
> > https://www.hpl.hp.com/hosted/linux/mail-archives/gc/
More information about the Gc