[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	09/04/20 15:09:27

Modified files:
	cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.i3 
	                                      ThreadPosix.m3 
	                                      ThreadPosixC.c 
	cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadF.i3 
	                                        ThreadPThread.i3 
	                                        ThreadPThread.m3 
	                                        ThreadPThreadC.c 
	cm3/m3-libs/m3core/src/thread/WIN32/: ThreadF.i3 ThreadWin32.m3 
	                                      m3makefile 
Added files:
	cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.i3 
	                                      ThreadWin32C.c 

Log message:
	convert more code to C
	
	This trades some thin C wrappers for more code in C but
	with a general reduction in "wrappers".
	In particular, users of thin wrappers are written in C.
	
	It is NOT clearly worthwhile.
	
	The wrappers that are gone are:
	pthread_setspecific_activations
	heapCond wrappers
	heapMu wrappers
	
	The functions that are now implemented in C for pthreads are:
	GetActivation
	SetActivation (and new SetActivationUnsafeFast, when initialization must have already occured)
	PushEFrame
	PopEFrame
	GetCurrentHandlers
	SetCurrentHandlers
	LockHeap
	UnlockHeap
	BroadcastHeap
	WaitHeap
	
	posix and Win32 vary somewhat.
	
	Win32 C:
	GetActivation
	SetActivation
	PushEFrame
	PopEFrame
	GetCurrentHandlers
	SetCurrentHandlers
	LockHeap
	UnlockHeap
	BroadcastHeap, but it just calls back to the Modula-3
	WaitHeap, but it just calls back to the Modula-3
	
	posix user threads:
	PushEFrame -- just due it being extern, calls back to the Modula-3
	PopEFrame -- just due it being extern, calls back to the Modula-3
	
	On the Win32 side, there is also a reduction in dependency on cloned headers, particularly
	the static allocation of CRITICAL_SECTION, though this is an area (Win32 cloned headers)
	I've generally left alone and probably will continue to.
	Win32 in a sense has multiplicity comparable to Posix:
	3 kernels: 9x, NT, CE
	but 9x is only x86 and is binary compatible with NT/x86
	CE is not binary compatible with 9x/NT, but does have processor overlap
	(at least, .dll names change)
	many processors: x86, AMD64, ARM (CE), PowerPC (historical NT, CE, Xbox360), Alpha (historical), MIPS (historical NT,
	current CE?), SH (CE), Itanium, SH (CE), I860 (never shipped?)
	32bit and 64bit
	
	but it seems like less of a problem?
	Well, Modula-3 has only ported to Win32/x86 so far..
	
	On the Win32 side this is just a step short of eliminating a thread local that has already been eliminated
	from the pthread side (ie: activation vs. handlers -- store the handlers
	stack in the activation). (Probably no point for posix user threads.)
	
	some "vertical compression" wrt #ifdef apple
	some name compression wrt "handle"