[Gc] Win32 thread support
tum at veridicus.com
Tue Mar 29 16:51:12 PST 2005
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 notifying 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
> I'm leaning towards (2). Opinions?
> Gc mailing list
> Gc at linux.hpl.hp.com
More information about the Gc