[M3commit] CVS Update: cm3

[Jay]

Hm. So I guess the point then is to return one "reasonable" integer, and
"reasonable" is actually defined as
 
(coredump << 15) | (termsig << 8) | exitcode
 
That's the point of the repacking?
and coredump and termsig are usually 0.
 
Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?
Uwaitpid.c was a good portable method I think.
It was based on the example code in online Posix docs (which you originally pointed me to).
 
 - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Mon, 12 Jan 2009 22:25:25 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] CVS Update: cm3




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