[M3devel] cloning headers vs. indirection/win32?

[Jay K]

Actually it appears the indirection is needed for CRITICAL_SECTION.

WinNT.i3:

 

(* NOTE: "PRTL_CRITICAL_SECTION" is declared as a Modula-3 opaque

   type and then immediately revealed so that "EnterCriticalSection()"
   and "LeaveCriticalSection()" won't require checks by the GC wrapper
   routines.  Clearly, if a Windows critical section is inside an M3
   traced ref (which moves!) the system is going to crash.  Hence, the
   extra GC check isn't needed. *)

TYPE   PRTL_CRITICAL_SECTION <: ADDRESS;
REVEAL PRTL_CRITICAL_SECTION = UNTRACED BRANDED "WinNT.PRTL_CRITICAL_SECTION"
                               REF RTL_CRITICAL_SECTION;

 

 

But we could still have the global locks (slotLock, activeLock, initLock, perfLock etc.) be "direct" CRITICAL_SECTIONS

and just the "dynamic" ones (Thread.Mutex) have the indirection.

 

 

 - Jay
 


From: jay.krell at cornell.edu
To: m3devel at elegosoft.com
Date: Sat, 12 Dec 2009 06:47:28 +0000
Subject: [M3devel] cloning headers vs. indirection/win32?



cloning headers vs. indirection/win32
 

So..I've been a champion of pushing code into C to avoid cloning headers.
 

I'm not sure the following statement is logical:
  It is easier to clone "windows.h" than "libc.h".
 

The possible logic is that there is less variation.
There is very little #ifdef in windows.h, whereas "libc.h" contains
both #ifdefs and there are to some extent n different versions.
 

Another possible explanation is that windows.h was cloned long ago
not by me and "libc.h" I've had to deal with more, on "new" systems.
 

It is an exaggeration to say OpenBSD/NetBSD/FreeBSD/Linux/Solaris/Darwin etc.
are "completely" different independent rewrites but it is also an
exaggeration to say they are "the same".
It is tempting to say the stat struct is the only problem, but it isn't.
 
 
If it IS logical, then some of this could/should be undone for Windows.
In particular I'm pretty sympathetic to having the Modula-3 code
use Initialize/Enter/LeaveCriticalSection directly.

 
With the following caveats:
  - maybe it isn't logical
  - as things are currently, there is more opportunity to merge pthreads and Win32 implementation
 

Going "back" to a somewhat more optimized Win32 implementation is a bit of a barrier
to merging them.
 

I'll probably things asis in this regard.
 

You know..to be "consistent", I should go through ThreadWin32.m3's:
 

FROM WinNT IMPORT LONG, HANDLE, DWORD, UINT32;
FROM WinBase IMPORT WaitForSingleObject, INFINITE,
    CloseHandle, CreateThread, ResumeThread, Sleep,
    SuspendThread, GetThreadContext, SetLastError, GetLastError,
    CREATE_SUSPENDED, GetCurrentThreadId, InterlockedCompareExchange,
    InterlockedExchange, InterlockedIncrement, InterlockedDecrement,
    SetEvent, WAIT_OBJECT_0, CreateEvent, WaitForMultipleObjects;
FROM ThreadContext IMPORT PCONTEXT;
 
 
and reduce those and/or wrap them in C like is done for m3core/unix.
 

Well, maybe. Constants are easy, plus statically link a la hand.obj/Uconstants.obj.
Functions are easy.
"base" types like LONG, HANDLE, DWORD, UINT32 we just go ahead and clone.
 

 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20091212/d3f4ce39/attachment-0002.html>