Remember that Rotor has a different GC than the CLR - their scheduling strategies are radically different. Rotor will only poll at safe points within JIT compiled code or from within the execution engine, and so there is no synchronization magic that needs to happen for the benefit of the GC (although there *is* still sync magic that needs to happen for other reasons, such as transitions between managed and unmanaged code...threads.cpp is a good place to go to observe the dance between the managed thread and the PAL thread).
There is no relationship between poll calls coming from emitted code and thread aborts (since the Rotor approach is much simpler than the pre-emptive approach that the CLR takes). You will see calls that remain in the code that are checking for pre-emptive GC - it was easier to leave these in than to find all and eradicate. Sorry in advance for that :) With regard to thread abort in Rotor (which is an interesting exception codepath to look at), the challenge is to "keep control" of the execution engine while unwinding the stack for the thread being killed. The execution engine has a number of control structures *within* the stack (see frames.h and also the jit prolog) that need to be correctly backed out. I will clarify that the Rotor GC is different from the CLR GC in the book chapter, thanks. The short description of the Rotor GC that I use in slides is: Rotor has a polling generational collector that uses two generations plus a separate large object heap. The younger generation is always compacted by "promotion" (copying into the elder generation), while the elder generation uses a mark and sweep algorithm, with first fit allocation. There is support for interior pointer tracing that uses a write barrier and a "remembered generation," which facilitates ECMA managed pointers and byref semantics. -- David Stutz -----Original Message----- From: Bill Conroy [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 01, 2002 10:12 AM To: [EMAIL PROTECTED] Subject: [DOTNET-ROTOR] CLR and Thread Safe Points I just read through the chapter 7 preview, very good BTW. I had a question about the part on Polling the GC to say the thread is at a safe point. I recalled reading in the .NET SDK docs[1] that aborting a thread (Thread.Abort) will require the CLR to wait till the thread is at a safe point to abort it. Why is this? Because the CLR wants to be nice and not just hijack the thread and send the exception? Because the CLR Threads don't necessarily need to map to OS threads(although I think all CLR implementations now do)? anything to do with the Stack, like what GC needs? ??? TIA -bc [1] ms- help://MS.NETFrameworkSDK/cpguidenf/html/cpconthreadsuspendgarbagecollec tion safepoints.htm
