[M3commit] waitpit

[Tony Hosking]

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.edu
> To: hosking at cs.purdue.edu
> CC: m3commit at elegosoft.com
> Subject: RE: waitpit
> Date: Tue, 13 Jan 2009 05:50:43 +0000
>
> 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).
> 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, the
> ones 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.edu
> To: hosking at cs.purdue.edu
> CC: m3commit at elegosoft.com
> Subject: RE: [M3commit] CVS Update: cm3
> Date: Mon, 12 Jan 2009 12:08:29 +0000
>
> 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.edu
> To: jay.krell at cornell.edu
> Date: Mon, 12 Jan 2009 22:25:25 +1100
> CC: m3commit at elegosoft.com
> Subject: 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/c425bde5/attachment-0002.html>