Here is good information about difference between foreground process groups and background:
https://www.win.tue.nl/~aeb/linux/lk/lk-10.html

Shortly, there is only one process group which is foreground, you can get it with tcgetpgrp(fd) or set it with tcsetpgrp(fd,pgrp). To setup process group of the process use setpgid(pid, pgid);

You can detect whether another process received a signal by ptracing it. If you are only ptracing for signals, then the performance penalty shouldn't be too severe.

Shachar

On 24/11/16 12:35, unDEFER wrote:
> On Wednesday, 23 November 2016 at 07:18:27 UTC, Shachar Shemesh wrote:
>
>> The shell does that for background processes. I think it takes away
>> the TTY from its children, and this way, when they try to read from
>> stdin, they get SIGSTOP from the system.
>>
>> I'm not sure what the precise mechanism is.
>>
>> There are flags passed to wait which will cause it to report when a
>> child gets SIGSTOP.
>>
>> Hope this helps,
>> Shachar
>
> So, I have found with strace, this signal is SIGTTIN is special signal
> which sends to _background_ task when it tries to read from terminal.
>
> So it is possible such detect when I will write not simple pipeProcess,
> but will write terminal emulator.
> Thank you.

The program which stops even run without "&":

#!/usr/bin/rdmd
import std.stdio;
import std.file;
import std.string;

import core.sys.posix.unistd;
import core.stdc.errno;
import core.stdc.string;

void main()
{
    int res = core.sys.posix.unistd.tcsetpgrp(0, getppid());
    if (res != 0)
    {
        writefln("tcsetpgrp error: %s", fromStringz(strerror(errno)).idup());
        return;
    }

    foreach (line; stdin.byLine)
    {
        writefln(line);
    }
}


But really it is not decision.. The program stops not because where is no input, but because there is other process reading terminal..
It is not that I need..

On 24/11/16 17:58, unDEFER wrote:

> But really it is not decision.. The program stops not because where is
> no input, but because there is other process reading terminal..
> It is not that I need..

You can write a wrapper program (let's call it wrp). Wrp can redirect your program's input though itself, and play with the session foreground based on whether there is input pending or not.

This way, your program will stop if the combination of two things happen:
1. It is waiting for input
and
2. There is none

This is, I think, what you want.