[M3commit] waitpid

[Jay]

 > (are there systems that encode non-zero successful exit status for processes?).  Hmm. 
 
I don't know, but I read that Posix says something like "zero is zero".
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).
 
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. :)
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.
 
Nevertheless, a "rich" exit code has its uses. Like "number of files copies" or such various common conditions.
But maybe we don't care.
 
 > I suspect the packing was there to ensure that current clients were able to do that reliably 
 
I don't follow.
Do you mean, like, guarding against "zero is not zero", such as, like, the filler being "random"?
 
I'll try poke around.
 
In the meantime, see Uexec.RepackStatus that I put in?
 
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.
 
ps: The Darwin PPC 10.4 dylibs don't have make/get/set/swapcontext either.
I think I checked both System.dylib and libc.dylib.
A "hybrid" where some platforms use setjmp/long and some use context is probably ok.
A larger issue here..another thread...
 
 - Jay



From: hosking at cs.purdue.eduTo: jay.krell at cornell.eduDate: Wed, 14 Jan 2009 11:25:07 +1100CC: m3commit at elegosoft.comSubject: Re: [M3commit] waitpit


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.

On 14 Jan 2009, at 10:59, Jay wrote:

  > 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). It looks like I added SchedulerPosix.WaitProcess only in 2008, while fixing the inefficient waitpid in libm3,so it wasn't some long standing interface, and changing it very reasonable.Had I only noticed sysutils at the time, I /might/ have thought to define it the way you did.(Still the bootstrap issue, neither WaitProcess signature is in older m3core.)  - Jay

From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: waitpitDate: Tue, 13 Jan 2009 05:50:43 +0000I 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).Maybe I misread it, between returning the pid/success vs. the status word?I had added the new interface SchedulerPosix.DoesWaitPidYield, but left others asis.Now, true, I'm arguing both sides, since I did make Uerror.i3 incompatible with some clients.Exposing more information like that seems a good solution, leaving the next level down to waitpid(0) or waitpid(nohang).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. I think the problem with the encoded exit status it is just a bit "wierd", and hardly anyone would want to use it asis.The repacked value makes more sense? Slightly?Hm..how about this...?  interface Uexec; <*external Uexec_WIFEXITED> PROCEDURE WIFEXITED(int status):BOOLEAN;etc. the various other macros/functions in Posix, well, at least two or three of them, theones that access the relevant fields. Uexec.c  typedef size_t BOOLEAN; /* ? safe at least, to return a full word's worth of bits */    #define TRUE 1    #define FALSE 1     BOOLEAN Uexec_WIFEEXITED(int status)  {      return WIFEEXITED(status) ? TRUE : FALSE;    } That fits one of the molds well imho.I like what I had in Uwaitpid, but it is hard to argue for it vs. this.They are very similar.This has the advantage of only returning what is asked for.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. 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). Ok?  - Jay

From: jay.krell at cornell.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: Mon, 12 Jan 2009 12:08:29 +0000Hm. 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/20090114/fdb40311/attachment-0002.html>