<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
cvsweb is a pain imho, so diff attached<BR><BR><BR> <BR>> Date: Sun, 22 Nov 2009 10:19:17 +0000<BR>> To: m3commit@elegosoft.com<BR>> From: jkrell@elego.de<BR>> Subject: [M3commit] CVS Update: cm3<BR>> <BR>> CVSROOT: /usr/cvs<BR>> Changes by: jkrell@birch. 09/11/22 10:19:17<BR>> <BR>> Modified files:<BR>> cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.i3 <BR>> ThreadWin32.m3 <BR>> ThreadWin32C.c <BR>> <BR>> Log message:<BR>> Win32 ProcessStacks had a hack where if the stack pointer was<BR>> more than 10K below the stack top, it would use VirtualQuery<BR>> to ensure the pages are readable.<BR>> <BR>> The comment was that this was to workaround Windows 95 sometimes<BR>> returning incorrect stack pointers.<BR>> <BR>> While I'm not testing Windows 95 here, and I should, modify the code<BR>> like so:<BR>> <BR>> At thread creation (and special case first thread), compute<BR>> the stack bounds accurately. (again, only tested on NT)<BR>> <BR>> Move GetThreadContext from ProcessStacks to SuspendOthers.<BR>> <BR>> When we GetThreadContext, if the stack is not in bounds,<BR>> treat it like a "busy" thread and resume it and try again later.<BR>> <BR>> NOTE that GetThreadContext is documented as not working<BR>> on the current thread, but the previous code did<BR>> exactly that. Perhaps that was the problem?<BR>> <BR>> The current thread's stack pointer is trivial to compute of course,<BR>> no need for GetThreadContext.<BR>> <BR>> Testing is advised on Win9x, though I personally<BR>> haven't run that in years and hardly ever did.<BR>> <BR>> In the previous code, see of course ProcessStacks, and VerifySP.<BR>> This likely had the affect as well of, when the stack went<BR>> beyond 10K, to round the stack pointer down to the next page,<BR>> scanning a little extra garbage (which if you consider<BR>> that "most objects die young", probably had a good chance<BR>> of causing retention of otherwise garbage? But I have no data.)<BR>> <BR>> (Nice side effect here, of course, is decreased dependency on cloned headers,<BR>> since I always strive to use C to interact with the underlying system<BR>> that is described with C headers.)<BR>> <BR>> Unfortunate side affect here is increased memory use because<BR>> the CONTEXT is now in Activation, in order to get from<BR>> SuspendOthers to ProcessStacks.<BR>> <BR>> We might do better to allocate an array of CONTEXT in SuspendOthers.<BR>> <BR>> We might do better also to use a "mini context" since we only use<BR>> a small fraction of the context (just the control and integer registers,<BR>> not the rather larger floating point state nor the segment registers,<BR>> debug registers, status flags, etc. since they can't contain pointers..<BR>> or can they? well, not with our backend..hm)<BR>> <BR>> Furthermore, of course, we should abstract this code to not be so x86 specific.<BR>> <BR>> With this change, the stack bounds are very well known, and the "end"<BR>> value is "just past the end", the first byte of the first page after the stack.<BR>> It might be wise to subtract one from this.<BR>> <BR>> Previously we used an approximate end of stack that pointed to an actual untraced<BR>> value on the stack.<BR>> <BR>> NoteStackLocations does subtract ADRSIZE(ADDRESS) though.<BR>> <BR>> Note that ThreadPosix.m3 could also implement such precise stackbase.<BR>> ThreadPThread.m3 probably often could, like with the functions on OpenBSD (broken) and FreeBSD, etc.<BR>> <BR> </body>
</html>