[M3commit] waitpit

[Jay]

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.eduTo: hosking at cs.purdue.eduCC: m3commit at elegosoft.comSubject: RE: [M3commit] CVS Update: cm3Date: 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.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/20090113/5ebe737c/attachment-0002.html>