[Gc] Win32 thread support
hans.boehm at hp.com
Tue Mar 29 15:44:05 PST 2005
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
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?
More information about the Gc