[M3commit] CVS Update: cm3

Tony Hosking hosking at cs.purdue.edu
Mon Jan 12 12:25:25 CET 2009


On 12 Jan 2009, at 21:11, Jay wrote:

>  > 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 didn't look too closely at that.  I wanted something that retained  
the simplicity of calling waitpid as:

PROCEDURE waitpid(pid: int; VAR status: int; options: int): int;

>  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?

I don't think so -- Uexec is still there.

>  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..

But really, clients of waitpid/SchedulerPosix.WaitProcess should be  
prepared to shift the status return value correctly!  After all, the  
interface doc for Process.Wait indicates that the return value is the  
status word.

>  I'll see about Cygwin pthreads.

Yes, it would be a more coherent solution.

>
>
>  - 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/d9485f79/attachment-0002.html>


More information about the M3commit mailing list