Re[2]: [Gc]: Patch for WinCE: a change in WinMain redirection

Ivan Maidanski ivmai at mail.ru
Thu Sep 24 04:04:27 PDT 2009


Hi!

"Boehm, Hans" <hans.boehm at hp.com> wrote:
> I'm intentionally not commenting (as opposed to not getting around to it :-( ) on this one, since I'm not a Windows CE expert.

Ok. In retrospection, all WinCE code had emerged between gc5.4 (1999) and gc6.0 (2001), and hasn't been changed up to recently (by myself). Unfortunately, the purpose of WinMain wasn't documented. Looking in gc6.0 win32_thread.c, it's clear that the WinCE main thread was neither registered (as registering was done either by GC_CreateThread (WinCE only) or by DllMain (Win32 only)) nor stopped and scanned.
get_stack_base() (which uses VirtualQuery) was used only for non-main threads.

Now (even before this patch), the main thread is registered, stopped and scanned. It works at least for WinCE 5.0. VirtualQuery() works also for main thread (for WinCE 5.0).

The other reason for WinMain() could theoretically be the need to destroy the locks on process exit, but MSDN docs say nothing about that it's obligatory on WinCE.

So, in the absence of objections, I've checked in this patch.

The major reasons are:
- no need for WinMain redirection and no WinMain symbol collision;
- gc could be usable as DLL;
- a fake GC thread is not created and maintained (thus more user space is free (a thread reserves 1 MiB for its stack by default) and faster world start/stop and scanning);
- WinCE threads GC model now equals Win32 one (except for stack bottom determination).

The original (old) WinCE behavior is available by using -DGC_WINMAIN_REDIRECT (both at compile and at use time). (This option also works for Win32.)

PS. For the old-style WinMain(), I'll also set thread_blocked_sp to a local var before calling WaitForSingleObject() (equivalent to calling GC_do_blocking).

> > From: gc-bounces at napali.hpl.hp.com 
> > [mailto:gc-bounces at napali.hpl.hp.com] On Behalf Of Ivan Maidanski
> > Hi!
> > 
> > This patch (ivmai145.diff) comes from my following 
> > conclusions (for WinCE):
> > - WinMain (without GC_ prefix) exported from gc.lib may 
> > result in a linker symbols collision;
> > - sometimes it's needed to tune GC before calling GC_INIT() 
> > (so, it's impossible relay on WinMain supplied by GC).
> > 
> > It seems that a WinCE application could be built in the same 
> > same style as a Win32 one, i.e. only have GC_INIT() (without 
> > create a separate thread for GC_WinMain) at start-up and 
> > without GC locks obligatory freeing, but the experimentation 
> > isn't done yet.
> > 
> > In this patch, GC_WINMAIN_REDIRECT macro is introduced (only 
> > if Win32 threads):
> > - at build, if it's defined then WinMain is exported from GC, 
> > otherwise not (this doesn't depend on MSWINCE macro);
> > - at import, this only defines WinMain as GC_WinMain (this 
> > doesn't depend on MSWINCE macro neither).
> > 
> > So, if someone wants the old behavior (for WinCE) then he 
> > should explicitly pass -D GC_WINMAIN_REDIRECT (both at build 
> > and use) thus confirming he wants WinMain redirection. (This 
> > approach is similar to the story of DllMain-based 
> > registration which had been implicit earlier and then the 
> > behavior changed requiring GC_use_DllMain() to be called to 
> > act in the old style.)
> > 
> > Any opinion? (Greatly appreciated.)

Bye.


More information about the Gc mailing list