<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Actually it appears the indirection is needed for CRITICAL_SECTION.<BR>
WinNT.i3:<BR>
<BR>
(* NOTE: "PRTL_CRITICAL_SECTION" is declared as a Modula-3 opaque<BR>
type and then immediately revealed so that "EnterCriticalSection()"<BR> and "LeaveCriticalSection()" won't require checks by the GC wrapper<BR> routines. Clearly, if a Windows critical section is inside an M3<BR> traced ref (which moves!) the system is going to crash. Hence, the<BR> extra GC check isn't needed. *)<BR>
TYPE PRTL_CRITICAL_SECTION <: ADDRESS;<BR>REVEAL PRTL_CRITICAL_SECTION = UNTRACED BRANDED "WinNT.PRTL_CRITICAL_SECTION"<BR> REF RTL_CRITICAL_SECTION;<BR>
<BR>
<BR>
But we could still have the global locks (slotLock, activeLock, initLock, perfLock etc.) be "direct" CRITICAL_SECTIONS<BR>
and just the "dynamic" ones (Thread.Mutex) have the indirection.<BR>
<BR>
<BR>
- Jay<BR> <BR>
<HR id=stopSpelling>
From: jay.krell@cornell.edu<BR>To: m3devel@elegosoft.com<BR>Date: Sat, 12 Dec 2009 06:47:28 +0000<BR>Subject: [M3devel] cloning headers vs. indirection/win32?<BR><BR>
<STYLE>
.ExternalClass .ecxhmmessage P
{padding:0px;}
.ExternalClass body.ecxhmmessage
{font-size:10pt;font-family:Verdana;}
</STYLE>
cloning headers vs. indirection/win32<BR> <BR><BR>So..I've been a champion of pushing code into C to avoid cloning headers.<BR> <BR><BR>I'm not sure the following statement is logical:<BR> It is easier to clone "windows.h" than "libc.h".<BR> <BR><BR>The possible logic is that there is less variation.<BR>There is very little #ifdef in windows.h, whereas "libc.h" contains<BR>both #ifdefs and there are to some extent n different versions.<BR> <BR><BR>Another possible explanation is that windows.h was cloned long ago<BR>not by me and "libc.h" I've had to deal with more, on "new" systems.<BR> <BR><BR>It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc.<BR>are "completely" different independent rewrites but it is also an<BR>exaggeration to say they are "the same".<BR>It is tempting to say the stat struct is the only problem, but it isn't.<BR> <BR> <BR>If it IS logical, then some of this could/should be undone for Windows.<BR>In particular I'm pretty sympathetic to having the Modula-3 code<BR>use Initialize/Enter/LeaveCriticalSection directly.<BR><BR> <BR>With the following caveats:<BR> - maybe it isn't logical<BR> - as things are currently, there is more opportunity to merge pthreads and Win32 implementation<BR> <BR><BR>Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier<BR>to merging them.<BR> <BR><BR>I'll probably things asis in this regard.<BR> <BR><BR>You know..to be "consistent", I should go through ThreadWin32.m3's:<BR> <BR><BR>FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32;<BR>FROM WinBase IMPORT WaitForSingleObject, INFINITE,<BR> CloseHandle, CreateThread, ResumeThread, Sleep,<BR> SuspendThread, GetThreadContext, SetLastError, GetLastError,<BR> CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange,<BR> InterlockedExchange, InterlockedIncrement, InterlockedDecrement,<BR> SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects;<BR>FROM ThreadContext IMPORT PCONTEXT;<BR> <BR> <BR>and reduce those and/or wrap them in C like is done for m3core/unix.<BR> <BR><BR>Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj.<BR>Functions are easy.<BR>"base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone.<BR> <BR><BR> - Jay<BR><BR> </body>
</html>