[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	09/11/22 10:19:17

Modified files:
	cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.i3 
	                                      ThreadWin32.m3 
	                                      ThreadWin32C.c 

Log message:
	Win32 ProcessStacks had a hack where if the stack pointer was
	more than 10K below the stack top, it would use VirtualQuery
	to ensure the pages are readable.
	
	The comment was that this was to workaround Windows 95 sometimes
	returning incorrect stack pointers.
	
	While I'm not testing Windows 95 here, and I should, modify the code
	like so:
	
	At thread creation (and special case first thread), compute
	the stack bounds accurately. (again, only tested on NT)
	
	Move GetThreadContext from ProcessStacks to SuspendOthers.
	
	When we GetThreadContext, if the stack is not in bounds,
	treat it like a "busy" thread and resume it and try again later.
	
	NOTE that GetThreadContext is documented as not working
	on the current thread, but the previous code did
	exactly that. Perhaps that was the problem?
	
	The current thread's stack pointer is trivial to compute of course,
	no need for GetThreadContext.
	
	Testing is advised on Win9x, though I personally
	haven't run that in years and hardly ever did.
	
	In the previous code, see of course ProcessStacks, and VerifySP.
	This likely had the affect as well of, when the stack went
	beyond 10K, to round the stack pointer down to the next page,
	scanning a little extra garbage (which if you consider
	that "most objects die young", probably had a good chance
	of causing retention of otherwise garbage? But I have no data.)
	
	(Nice side effect here, of course, is decreased dependency on cloned headers,
	since I always strive to use C to interact with the underlying system
	that is described with C headers.)
	
	Unfortunate side affect here is increased memory use because
	the CONTEXT is now in Activation, in order to get from
	SuspendOthers to ProcessStacks.
	
	We might do better to allocate an array of CONTEXT in SuspendOthers.
	
	We might do better also to use a "mini context" since we only use
	a small fraction of the context (just the control and integer registers,
	not the rather larger floating point state nor the segment registers,
	debug registers, status flags, etc. since they can't contain pointers..
	or can they? well, not with our backend..hm)
	
	Furthermore, of course, we should abstract this code to not be so x86 specific.
	
	With this change, the stack bounds are very well known, and the "end"
	value is "just past the end", the first byte of the first page after the stack.
	It might be wise to subtract one from this.
	
	Previously we used an approximate end of stack that pointed to an actual untraced
	value on the stack.
	
	NoteStackLocations does subtract ADRSIZE(ADDRESS) though.
	
	Note that ThreadPosix.m3 could also implement such precise stackbase.
	ThreadPThread.m3 probably often could, like with the functions on OpenBSD (broken) and FreeBSD, etc.