[Gc] FW: Win32: Multiple threads already spawned prior to GC_init? GC Aborts due to unknown Thread!

Michael Paul Brandt michael at pdc.dk
Wed Jan 23 04:53:27 PST 2008


Dear Hans,

 

We are very curious about your opinion about the matter described in
posting below  a few weeks ago.

 

This could of course be a Win32 specific issue, but still, it seems very
generic by nature. A foreign, multithreaded host program (not using GC)
loads a dynamic library based on GC.  The GC knows only of the loading
thread and hence the problem occurs when another thread enters GC.

 

We have extended the GC with an explicit
attachThreadIfNotAlreadyAttached-like function that we call for each
thread requiring GC service. This works for us, but in general it is
cumbersome and difficult to ensure that this explicit attachment is
performed for each thread. We are still hoping for a generic solution
where gc_Init ensures that all threads are registered in GC. The only
difficulty we can spot is how to acquire the information the GC needs
per thread, when not running as them.

 

Kind regards,

 

Michael Brandt

Prolog Development Center A/S

Tel. +45 36360000

Mail: michael.brandt at pdc.dk

 

 

 

From: Michael Paul Brandt 
Sent: 3. januar 2008 23:23
To: gc at linux.hpl.hp.com
Cc: VIPDevelop
Subject: Win32: Multiple threads already spawned prior to GC_init? GC
Aborts due to unknown Thread!

 

Hello all,

 

We develop compilers and run-time systems for the Visual Prolog language
on Microsoft platforms. We have been using the Boehm-Demers-Weiser GC
for the past five years (currently v6.8) as part of our kernel runtime
DLL.  

 

Currently we are experiencing problems when running a Visual Prolog COM
component under Internet Information Server (IIS). Most likely because
the GC is called from an unknown thread. 

 

The details are as follows:

 

The GC.lib is compiled with Visual Studio 2005 and flags

 

WIN32;NDEBUG;_LIB;GC_WIN32_THREADS;SILENT;NO_DEBUGGING;ALL_INTERIOR_POIN
TERS;DONT_ADD_BYTE_AT_END;LARGE_CONFIG;VIP_ALLOC_STATISTICS;VIP_RUNTIME;
GC_DLL;USE_MUNMAP;VIP_SMART_ROOTS;_CRT_SECURE_NO_DEPRECATE;$(NOINHERIT)

 

Threads are attached and detached using the DllMain callback. We have
programmed our own VIPGC_register_dynamic_libraries function that
minimizes the GC root set such that "foreign" data segments aren't
considered roots.

 

We develop Visual Prolog COM DLLs. These COM DLLs are accessed from
Microsoft Internet Information Server (IIS) using COM Interop from C#.
The IIS uses a worker process with numerous worker threads to invoke our
COM DLL. Upon Vip7Kernel.dll loading we immediately call GC_init, but
only the loading thread gets registered in GC's thread structure. Now,
at some stage another IIS worker thread decides to call some Visual
Prolog code using the COM DLL which results in a call to the GC. The GC
decides to do some housekeeping and starts the mark phase, which require
all thread stacks to be pushed onto the mark stack.  The function
GC_push_all_stacks()of win32_threads.c is called and it pushes stacks
for all _registered_ threads and examines if current executing thread is
among the registered. If so, the variable found_me is set to true. The
function completes by verifying that found_me is indeed true or else it
aborts!

 

  if (!found_me) ABORT("Collecting from unknown thread.");

 

This is exactly what we experience in our embedded DLLs, since the
requesting thread has never been properly registered in the GC's thread
structure.

 

We have been through the GC mail archives and found no mentioning of
this thread issue. We have also reviewed the latest v7.0 code of the GC,
but this issue seems to remain a problem.

 

Would the proper solution (for us at least) be to enumerate all threads
of our process (using CreateToolhelp32Snapshot) and attach each
explicitly to the GC (right after GC_init is called)? Have anyone
encountered similar problems when embedding GC in "foreign" process
environments?

 

We appreciate all feedback. Thank you.

 

Michael Brandt

Prolog Development Center A/S

Tel. +45 36360000

Mail: michael.brandt at pdc.dk <mailto:michael.brandt at pdc.dk> 

 

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://napali.hpl.hp.com/pipermail/gc/attachments/20080123/7c834a98/attachment.htm


More information about the Gc mailing list