[M3devel] [M3commit] CVS Update: cm3

[Tony Hosking]

Jay,

I have to call it quits on this tonight.  As you can see, I've  
reverted the clients of SchedulerPosix.WaitProcess to do the re- 
packing based on the original definitions in Uexec.  We need to do a  
more wholesale check of the clients of Process.Wait and System.Wait to  
see who relies on particular endian-ness of the status word they  
return.  Really, those clients should be using proper bit-shifts and  
bit-masks to extract the right values rather than some endian- 
dependent RECORD layout defined in Uexec.  I think we can make this  
much cleaner if we can get rid of the re-packing.

I am still concerned that there is needless splitting of the threads  
files.  Perhaps ThreadPWait.m3 and ThreadPScheduler.m3 can be  
merged.   I still don't like either of those names, but we should  
avoid SchedulerPosix.m3 since ThreadPosix.m3 also exports  
SchedulerPosix.

It would really be much nicer if you could get CygWin to run using  
PTHREAD instead of the weird WIN32 hybrid.

I'm hoping I can get back to more productive pursuits tomorrow...   
today has been pretty much destroyed as a result of these commits...

The productive things are improving concurrency in the garbage  
collector -- I'd like to be able to do collection in parallel... ;-)

On 12 Jan 2009, at 10:20, Antony Hosking wrote:

> CVSROOT:	/usr/cvs
> Changes by:	hosking at birch.	09/01/12 10:20:33
>
> Modified files:
> 	cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3
> 	                                ThreadPWait.m3
> 	cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3
> 	cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3
> 	                                     m3makefile
> 	cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3
> 	cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile
>
> Log message:
> 	Try to clean up mess with Process.Wait and System.Wait based on  
> waitpid.
> 	
> 	Packing is now returned to Process.Wait and System.Wait where it  
> used to be.
> 	
> 	Not sure if this re-packing is needed by clients, but should verify.