[M3commit] CVS Update: cm3

[Jay]

 > 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
 
 Wasn't Uwaitpid.c a good portable way to do exactly that?  I guess it can be written in Modula-3 though, if the headers are cloned as they are. Aren't {I386,AMD64}_DARWIN broken here?  Besides all "my" ports, which don't define those types.  Yeah yeah, all I have to do is switch on endian and I can introduce them..
 I'll see about Cygwin pthreads. 
 - Jay> Date: Mon, 12 Jan 2009 10:20:33 +0000> To: m3commit at elegosoft.com> From: hosking at elego.de> Subject: [M3commit] CVS Update: cm3> > 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.> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20090112/4c5a6a5f/attachment-0002.html>