On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:

>
> In your case the segfault would cause SIGSEGV (signal 11) to be sent to
> the process, and the the above test would print "Process terminated by
> signal 11".
>
> See "man wait" for more info.

That's where I got my info (or rather /usr/include/bits/waitstatus.h)

>
>
> std.process is currently undergoing a complete redesign, so the current
> situation should improve in the near future. :)
>
> -Lars

That's good to hear. And since you're an expert in this stuff, does this my code look alright?

import std.typecons;
static import std.c.process;
import std.functional;
import std.stdio;
import std.string;

alias Tuple!(ubyte, "status",ubyte, "term", ubyte, "sig",bool,"signaled",bool, "stopped", bool,"continued",bool, "coredumped") PID;

PID toPID(int p){
    PID pid;
    pid.status = cast(byte)((p & 0xff00) >> 8);
    pid.term = cast(byte)(p & 0xff);
    pid.sig = cast(byte)(p & 0x7f);
    pid.signaled = pid.sig != 0 && pid.sig != 0x7f;
    pid.coredumped = cast(bool)(p & 0x80);
    pid.stopped = pid.term == 0x7f;
    pid.continued = p == 0xffff;
    return pid;
}

int fromPID(PID pid){
    if(pid.signaled) return pid.term;
    return pid.status;
}

alias compose!(toPID, std.c.process.system, toStringz) system_p;
alias compose!(fromPID, system_p) system;

On Tue, 04 May 2010 08:55:36 -0500, Ellery Newcomer wrote:

> On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
> 
> 
>> In your case the segfault would cause SIGSEGV (signal 11) to be sent to the process, and the the above test would print "Process terminated by signal 11".
>>
>> See "man wait" for more info.
> 
> That's where I got my info (or rather /usr/include/bits/waitstatus.h)
> 
> 
>>
>> std.process is currently undergoing a complete redesign, so the current situation should improve in the near future. :)
>>
>> -Lars
> 
> That's good to hear. And since you're an expert in this stuff, does this my code look alright?
> 
> import std.typecons;
> static import std.c.process;
> import std.functional;
> import std.stdio;
> import std.string;
> 
> alias Tuple!(ubyte, "status",ubyte, "term", ubyte, "sig",bool,"signaled",bool, "stopped", bool,"continued",bool, "coredumped") PID;
> 
> PID toPID(int p){
>      PID pid;
>      pid.status = cast(byte)((p & 0xff00) >> 8); pid.term = cast(byte)(p
>      & 0xff);
>      pid.sig = cast(byte)(p & 0x7f);
>      pid.signaled = pid.sig != 0 && pid.sig != 0x7f; pid.coredumped =
>      cast(bool)(p & 0x80); pid.stopped = pid.term == 0x7f;
>      pid.continued = p == 0xffff;
>      return pid;
> }
> 
> int fromPID(PID pid){
>      if(pid.signaled) return pid.term;
>      return pid.status;
> }
> 
> alias compose!(toPID, std.c.process.system, toStringz) system_p; alias
> compose!(fromPID, system_p) system;


Thanks for posting this. Just curious -- why did you choose to model PID as a tuple instead of a struct? I'm not clear on what the tradeoffs are.

Best,
Graham

On 05/04/2010 09:51 AM, Graham Fawcett wrote:
>
> Thanks for posting this. Just curious -- why did you choose to model PID
> as a tuple instead of a struct? I'm not clear on what the tradeoffs are.
>
> Best,
> Graham

according to core.sys.posix.sys.wait, this is only valid for linux, grrr.

I don't think there is a difference, as a tuple is a glorified struct.

You just have to remember to use t.field instead of t.tupleof when iterating the elements in a foreach.

Mostly, I just love one liners.

On Tue, 04 May 2010 08:55:36 -0500, Ellery Newcomer wrote:
> On 05/04/2010 01:58 AM, Lars T. Kyllingstad wrote:
>> std.process is currently undergoing a complete redesign, so the current situation should improve in the near future. :)
>>
>> -Lars
> 
> That's good to hear. And since you're an expert in this stuff, does this my code look alright?
> 
> import std.typecons;
> static import std.c.process;
> import std.functional;
> import std.stdio;
> import std.string;
> 
> alias Tuple!(ubyte, "status",ubyte, "term", ubyte, "sig",bool,"signaled",bool, "stopped", bool,"continued",bool, "coredumped") PID;
> 
> PID toPID(int p){
>      PID pid;
>      pid.status = cast(byte)((p & 0xff00) >> 8); pid.term = cast(byte)(p
>      & 0xff);
>      pid.sig = cast(byte)(p & 0x7f);
>      pid.signaled = pid.sig != 0 && pid.sig != 0x7f; pid.coredumped =
>      cast(bool)(p & 0x80); pid.stopped = pid.term == 0x7f;
>      pid.continued = p == 0xffff;
>      return pid;
> }

Shouldn't 'term' and 'signaled' switch names?  It looks to me like 'term' will be nonzero if the process receives any signal, while 'signaled' will be only be true if it is a terminating signal, and not if it is a stop signal.

Otherwise it looks right, at least on Linux.  But why not use the core.sys.posix.sys.wait.Wxxx() functions?  Then it will automatically work on BSD and MacOS as well.


> int fromPID(PID pid){
>      if(pid.signaled) return pid.term;
>      return pid.status;
> }
> 
> alias compose!(toPID, std.c.process.system, toStringz) system_p; alias
> compose!(fromPID, system_p) system;

I didn't know about compose, that's nifty. :)

-Lars

On 05/04/2010 11:32 AM, Lars T. Kyllingstad wrote:
>
> Shouldn't 'term' and 'signaled' switch names?  It looks to me like 'term'
> will be nonzero if the process receives any signal, while 'signaled' will
> be only be true if it is a terminating signal, and not if it is a stop
> signal.
>

signaled corresponds to WIFSIGNALED, whatever that is, and takes its name.

term has no justification for its name; I just want something that is the same as what bash returns on segfault. I don't know what it does on BSD, though.

> Otherwise it looks right, at least on Linux.  But why not use the
> core.sys.posix.sys.wait.Wxxx() functions?  Then it will automatically
> work on BSD and MacOS as well.

Easy, I didn't know about that module when I wrote this.

alias Tuple!(int, "status",int, "signal", int, "termsig",bool, "signaled",bool, "stopped", bool,"continued") PID;

PID toPID(int p){
    PID pid;
    pid.status = WEXITSTATUS(p);
    pid.signal = (p & 0xff);
    pid.termsig = WTERMSIG(p);
    pid.signaled = WIFSIGNALED(p);
    pid.stopped = WIFSTOPPED(p);
    pid.continued = cast(bool) WIFCONTINUED(p); //why the eff is this defined as an int?
    return pid;
}

Is the coredump flag a linux-only thing?

On Tue, 04 May 2010 15:22:52 -0500, Ellery Newcomer wrote:

> On 05/04/2010 11:32 AM, Lars T. Kyllingstad wrote:
>>
>> Shouldn't 'term' and 'signaled' switch names?  It looks to me like 'term' will be nonzero if the process receives any signal, while 'signaled' will be only be true if it is a terminating signal, and not if it is a stop signal.
>>
>>
> signaled corresponds to WIFSIGNALED, whatever that is, and takes its name.
> 
> term has no justification for its name; I just want something that is the same as what bash returns on segfault. I don't know what it does on BSD, though.
> 
>> Otherwise it looks right, at least on Linux.  But why not use the core.sys.posix.sys.wait.Wxxx() functions?  Then it will automatically work on BSD and MacOS as well.
> 
> Easy, I didn't know about that module when I wrote this.
> 
> alias Tuple!(int, "status",int, "signal", int, "termsig",bool, "signaled",bool, "stopped", bool,"continued") PID;
> 
> PID toPID(int p){
>      PID pid;
>      pid.status = WEXITSTATUS(p);
>      pid.signal = (p & 0xff);
>      pid.termsig = WTERMSIG(p);
>      pid.signaled = WIFSIGNALED(p);
>      pid.stopped = WIFSTOPPED(p);
>      pid.continued = cast(bool) WIFCONTINUED(p); //why the eff is this
> defined as an int?

Don't know.  Since all the other WIF* tests return bool, that looks like a bug.


>      return pid;
> }
> 
> Is the coredump flag a linux-only thing?

No, it exists in BSD and MacOS as well, but it's not a part of the POSIX specification.  I assume that's why Sean didn't include it in the druntime headers.  According to the man page it's not available on AIX and SunOS, and probably others.

-Lars