[M3commit] CVS Update: cm3

[Jay K]

cvsweb is a pain imho, so diff attached


 
> Date: Sun, 22 Nov 2009 10:19:17 +0000
> To: m3commit at elegosoft.com
> From: jkrell at elego.de
> Subject: [M3commit] CVS Update: cm3
> 
> 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.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20091122/f6236467/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 2.txt
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20091122/f6236467/attachment-0002.txt>