[Gc] Win32 thread support

[Thong Nguyen]

Hi,

Have you considered api-hooking the CreateThread API?

Regards,

-Tum

> -----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
> 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/