[M3commit] CVS Update: cm3

Jay Krell jkrell at elego.de
Sun Mar 15 09:25:09 CET 2009


CVSROOT:	/usr/cvs
Changes by:	jkrell at birch.	09/03/15 09:25:09

Modified files:
	cm3/m3-libs/m3core/src/thread/PTHREAD/: ThreadPThread.i3 
	                                        ThreadPThread.m3 
	                                        ThreadPThreadC.c 
	cm3/m3-libs/m3core/src/unix/Common/: Upthread.i3 
	cm3/m3-libs/m3core/src/unix/cygwin/: Usysdep.i3 
	cm3/m3-libs/m3core/src/unix/darwin-common/: Usysdep.i3 
	cm3/m3-libs/m3core/src/unix/freebsd-common/: Usysdep.i3 
	cm3/m3-libs/m3core/src/unix/hpux-common/: Usysdep.i3 
	cm3/m3-libs/m3core/src/unix/linux-common/: Usysdep.i3 
	cm3/m3-libs/m3core/src/unix/netbsd-common/: Usysdep.i3 
	cm3/m3-libs/m3core/src/unix/openbsd-common/: Usysdep.i3 
	cm3/m3-libs/m3core/src/unix/solaris-common/: Usysdep.i3 

Log message:
	Remove platform-specificity of dynamically allocated pthread_mutex_t and pthread_cond_t.
	
	Replace them with UNTRACED REF ARRAY OF CHAR where
	size comes from a constant variable "implemented" in C.
	They were already UNTRACED REFs.
	This does not add any overhead/indirection beyond what was there.
	
	On platforms where they fit in a pointer, which is common but not universal,
	it would be nice to remove the heap allocation. However the allocation
	is on-demand and depends on there being a distinguished not-yet-initialized value -- NIL.
	That is why I have punted on making that optimization.
	
	Also wrap pthread_mutex_destroy to workaround bugs in HP-UX and Tru64.
	(This could be done in Modula-3.)
	
	Since we are now, in a sense, lying about the types pthread_cond_t and
	pthread_mutex_t, or at least changing how they can be used (or at
	least created), declare them in ThreadPThread.i3 instead of Upthread.i3.
	That is, if we are going to break unlikely existant consumers of Upthread.i3,
	break them more severely. That is also, basically nobody is meant
	to deal with pthread in Modula-3, except for purposes of establishing
	a portable Modula-3 library/interface, which is what ThreadPThread.m3 is doing.
	Exposing everything to everyone from the "unix" directory seems, perhaps, wrong.
	(Unless, perhaps, people are porting a bunch of C to Modula-3, just
	altering syntax but leaving library calls unchanged; then it is very reasonable.)
	
	Note that the mainstream headers are unchanged here actually.
	They could be drastically cut down.
	Or, wait until we have user thread support, then just stop using them.
	The commands about breaking existing clients applies to many platforms, but not all, yet.
	
	(Again I think it is worth pushing this internal stuff to a separate
	interface -- PThreadC.i3 but that was undone in the past.)




More information about the M3commit mailing list