[M3commit] CVS Update: cm3

[Jay Krell]

CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	08/12/31 21:05:27

Modified files:
	cm3/m3-libs/m3core/src/thread/: m3makefile 
	cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3 
	                                       m3makefile 
	cm3/m3-libs/m3core/src/thread/POSIX/: ThreadPosix.m3 
	cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.m3 
	cm3/m3-libs/m3core/src/thread/WIN32/: ThreadWin32.m3 m3makefile 
	cm3/m3-libs/m3core/src/unix/cygwin/: Unix.i3 
Added files:
	cm3/m3-libs/m3core/src/thread/: ThreadInternal.i3 
	                                ThreadPScheduler.m3 
	                                ThreadPWait.m3 
Removed files:
	cm3/m3-libs/m3core/src/thread/WIN32/: WaitProcessCygwin.m3 
	                                      WaitProcessWin32.m3 

Log message:
	move code around with the following goals
	
	fold the three implementations of WaitProcess down to two
	minor, would not be done if it was the only point
	This is ThreadPWait.m3.
	
	remove stub SchedulerPosix from NT386 AND NT386GNU
	presumably nobody calls the NT386 version, so also (half) minor
	
	give NT386GNU the real implementation of SchedulerPosix
	This is more significant then, e.g. working versions of IOWait (aka select).
	This is ThreadPScheduler.m3, moved out of ThreadPThread.m3.
	Note that the name is open to debate.
	There is this general problem that "P" for posix means two very different things.
	It means posix user/alarm threads and posix kernel threads.
	(Note that Win32 generalizes select to work on more than just sockets...
	either completion ports or WaitForMultipleObjects I assume the generalized analog..)
	
	provide a /tiny/ abstraction for Posix waitpid users to
	provide their own yielding if necessary
	This used by WaitProcess.
	It potentially for sysutils also, but sysutils can't depend on m3core changes
	due to bootstrapping against older m3core.
	
	The next step is to factor out m3core/threads/m3makefile into
	m3core/thread.quake so that sysutils can share its decision as to
	if kernel threads are in use and therefore if waitpid yields.
	Essentially to copy m3core ThreadPWait plus the other one liner.
	If we could rely on newer m3core, then sysutils could just call SchedulerPosix.DoesWaitPidYield().
	
	This may look scary but it is mainly only moving existing code around,
	and very small changes otherwise.
	Except for Cygwin which gets the significant improvement of a real SchedulerPosix.
	
	Since code was moved -- ThreadPThread.m3 split into three files, there
	was also a need for an interface so that code moved out of ThreadPThread
	could call back to private shared code there, and the other implementation
	in ThreadWin32. That is ThreadInternal.i3.
	It could be ThreadF.i3, but that would be unnecessarily exposed and worse,
	export a variable outside the package, which is a bad idea.
	Perhaps wrap up the variable in a function? Maybe.
	As well, ThreadF.i3 has three similar copies and this new content would be
	needed in two of them. Perhaps the three copies could be combined to one,
	with no-op stubs where functions don't make sense (as comments already
	indicate exist).
	
	If cygwin used pthreads, this wouldn't be needed at all.
	However, it is reasonable.
	Maybe go back and debug Cygwin pthreads again at some point...
	Maybe combine ThreadInternal.i3 and ThreadF.i3.
	F is "friend" -- aka expose internals to special people, not the
	public interface, but sometimes it is needed, thus "F" and "Internal"
	are synonyms and you should really never have both, but here they are.