<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
> (are there systems that encode non-zero successful exit status for processes?). Hmm. <BR>
<BR>
I don't know, but I read that Posix says something like "zero is zero".<BR>
Like, if child process calls exit(0) or _exit(0), then the full int status will be 0 (even if only 8 bits of exit's parameter are preserved).<BR>
<BR>
I thought I read long ago that VMS inverted the meaning, but then C development libraries had to reinvert it for source compatibility. Maybe I'll know better when I bring Modula-3 on VMS back. :)<BR>
Whatever I was reading gave EXIT_SUCCESS and EXIT_FAILURE as the only portable values...but certainly there is plenty of hardcoded exit(0), thus the theoretically compat hacks.<BR>
<BR>
Nevertheless, a "rich" exit code has its uses. Like "number of files copies" or such various common conditions.<BR>
But maybe we don't care.<BR>
<BR>
> I suspect the packing was there to ensure that current clients were able to do that reliably <BR>
<BR>
I don't follow.<BR>
Do you mean, like, guarding against "zero is not zero", such as, like, the filler being "random"?<BR>
<BR>
I'll try poke around.<BR>
<BR>
In the meantime, see Uexec.RepackStatus that I put in?<BR>
<BR>
And definitely look at what I did to ThreadPThread. Perhaps too contorted. Perhaps declare ackSem and mask as arbibrary int and the relevant functions taking ADDRESS, and see if initializing the variables with { 0 } will fix the problem I had on Darwin. Or, if not, I can put in accessor functions for the globals, leaving them static. That'll surely work, didn't think of it till just now.<BR>
<BR>
ps: The Darwin PPC 10.4 dylibs don't have make/get/set/swapcontext either.<BR>
I think I checked both System.dylib and libc.dylib.<BR>
A "hybrid" where some platforms use setjmp/long and some use context is probably ok.<BR>
A larger issue here..another thread...<BR>
<BR>
- Jay<BR><BR><BR>
<HR id=stopSpelling>
<BR>
From: hosking@cs.purdue.edu<BR>To: jay.krell@cornell.edu<BR>Date: Wed, 14 Jan 2009 11:25:07 +1100<BR>CC: m3commit@elegosoft.com<BR>Subject: Re: [M3commit] waitpit<BR><BR><BR>
<DIV><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV>Yeah, that's right. I think we should still ensure that clients of Process.Wait and System.Wait don't do anything more than check the non-zero status value that they return. I suspect the packing was there to ensure that current clients were able to do that reliably (are there systems that encode non-zero successful exit status for processes?). Hmm.</DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV><BR>
<DIV>
<DIV>On 14 Jan 2009, at 10:59, Jay wrote:</DIV><BR class=EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> > I think "what I was missing" here is the option of changing the Process.Wait or<BR> > SchedulerPosix.WaitProcess interface to return the status bits. I don't think this<BR> > is how it was before, (which I think was implied).<BR> <BR>It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3,<BR>so it wasn't some long standing interface, and changing it very reasonable.<BR>Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did.<BR>(Still the bootstrap issue, neither WaitProcess signature is in older m3core.)<BR> <BR> - Jay<BR><BR><BR>
<HR id=EC_stopSpelling>
<BR>From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>CC:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</A><BR>Subject: RE: waitpit<BR>Date: Tue, 13 Jan 2009 05:50:43 +0000<BR><BR>I think "what I was missing" here is the option of changing the Process.Wait or SchedulerPosix.WaitProcess interface to return the status bits. I don't think this is how it was before, (which I think was implied).<BR>Maybe I misread it, between returning the pid/success vs. the status word?<BR>I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.<BR>Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.<BR>Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).<BR>I think user threads are missing some code now, since ThreadPWait (but not ThreadPScheduler) was used by them. But I admit, I didn't build them either, so whether they worked or not, and whether I kept them working or not, don't know. They are never build by default.<BR> <BR>I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.<BR>The repacked value makes more sense? Slightly?<BR>Hm..how about this...?<BR> <BR> <BR>interface Uexec;<BR> <BR><*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;<BR>etc. the various other macros/functions in Posix, well, at least two or three of them, the<BR>ones that access the relevant fields.<BR> <BR>Uexec.c<BR> typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */ <SPAN class=EC_Apple-converted-space> </SPAN><BR> #define TRUE 1 <SPAN class=EC_Apple-converted-space> </SPAN><BR> #define FALSE 1 <SPAN class=EC_Apple-converted-space> </SPAN><BR> <BR> BOOLEAN Uexec_WIFEEXITED(int status)<BR> { <SPAN class=EC_Apple-converted-space> </SPAN><BR> return WIFEEXITED(status) ? TRUE : FALSE; <SPAN class=EC_Apple-converted-space> </SPAN><BR> }<BR> <BR>That fits one of the molds well imho.<BR>I like what I had in Uwaitpid, but it is hard to argue for it vs. this.<BR>They are very similar.<BR>This has the advantage of only returning what is asked for.<BR>Uwaitpid had the advantage of probably being faster -- less storage efficient, but fewer function calls / roundtrips and such, since WIFEEXITED is likely a macro and Modula-3 loses the inlining. Surely not a big deal either way. Both options are very portable.<BR> <BR>Then, the rejiggering/repacking of the bits can be done portably, without regard to endiannness and without regard to the bitfield layout of the int; the bitfields can go away, leaving just the int to be unpacked by these macros-wrapped-in-functions. (I believe it is portable defined as an int but I'll check).<BR> <BR>Ok?<BR> <BR> - Jay<BR><BR><BR>
<HR id=EC_EC_stopSpelling>
<BR><BR>From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>CC:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</A><BR>Subject: RE: [M3commit] CVS Update: cm3<BR>Date: Mon, 12 Jan 2009 12:08:29 +0000<BR><BR>Hm. So I guess the point then is to return one "reasonable" integer, and<BR>"reasonable" is actually defined as<BR> <BR>(coredump << 15) | (termsig << 8) | exitcode<BR> <BR>That's the point of the repacking?<BR>and coredump and termsig are usually 0.<BR> <BR>Anyway, I don't think even this 7/1/8/16 split is specified by Posix. Right?<BR>Uwaitpid.c was a good portable method I think.<BR>It was based on the example code in online Posix docs (which you originally pointed me to).<BR> <BR> - Jay<BR><BR><BR><BR><BR>
<HR id=EC_EC_EC_stopSpelling>
<BR><BR><BR>From:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</A><BR>To:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</A><BR>Date: Mon, 12 Jan 2009 22:25:25 +1100<BR>CC:<SPAN class=EC_Apple-converted-space> </SPAN><A href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</A><BR>Subject: Re: [M3commit] CVS Update: cm3<BR><BR><BR><BR><BR>
<DIV><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV style="WORD-WRAP: break-word"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV><BR></DIV></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></SPAN></DIV></SPAN></DIV>
<DIV>
<DIV>On 12 Jan 2009, at 21:11, Jay wrote:</DIV><BR class=EC_EC_EC_EC_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> > relies on particular endian-ness of the status<BR> > word they return. Really, those clients should<BR> > be using proper bit-shifts and bit-masks to extract<BR> > the right values rather than some endian- dependent RECORD layout defined in Uexec<BR> <BR> Wasn't Uwaitpid.c a good portable way to do exactly that?<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>I didn't look too closely at that. I wanted something that retained the simplicity of calling waitpid as:</DIV>
<DIV><BR></DIV>
<DIV>PROCEDURE waitpid(pid: int; VAR status: int; options: int): int;</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> I guess it can be written in Modula-3 though, if the headers are cloned as they are.<BR> Aren't {I386,AMD64}_DARWIN broken here?<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN></DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>I don't think so -- Uexec is still there.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> Besides all "my" ports, which don't define those types.<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR> Yeah yeah, all I have to do is switch on endian and I can introduce them..</DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>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.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"> I'll see about Cygwin pthreads.</DIV></SPAN></BLOCKQUOTE>
<DIV><BR></DIV>
<DIV>Yes, it would be a more coherent solution.</DIV><BR>
<BLOCKQUOTE><SPAN class=EC_EC_EC_EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=EC_EC_EC_EC_hmmessage style="FONT-SIZE: 10pt; FONT-FAMILY: Verdana"><BR><BR> - Jay<BR><BR>> Date: Mon, 12 Jan 2009 10:20:33 +0000<BR>> To:<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:m3commit@elegosoft.com">m3commit@elegosoft.com</A><BR>> From:<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><A href="mailto:hosking@elego.de">hosking@elego.de</A><BR>> Subject: [M3commit] CVS Update: cm3<BR>><SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> CVSROOT: /usr/cvs<BR>> Changes by: hosking@birch. 09/01/12 10:20:33<BR>><SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> Modified files:<BR>> cm3/m3-libs/m3core/src/thread/: ThreadPScheduler.m3<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> ThreadPWait.m3<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> cm3/m3-libs/m3core/src/thread/Common/: SchedulerPosix.i3<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> cm3/m3-libs/m3core/src/unix/Common/: UtimeC.c Uwaitpid.i3<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> m3makefile<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> cm3/m3-libs/libm3/src/os/POSIX/: ProcessPosixCommon.m3<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> cm3/m3-libs/sysutils/src/POSIX/: SystemPosix.m3 m3makefile<SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>><SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> Log message:<BR>> Try to clean up mess with Process.Wait and System.Wait based on waitpid.<BR>><SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> Packing is now returned to Process.Wait and System.Wait where it used to be.<BR>><SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR>> Not sure if this re-packing is needed by clients, but should verify.<BR>><SPAN class=EC_EC_EC_EC_Apple-converted-space> </SPAN><BR><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></DIV></SPAN><BR class=EC_Apple-interchange-newline></BLOCKQUOTE></DIV><BR></body>
</html>