Вопрос по статусу процесса

очевидно посылать управляющие сигналы из одного источника, а не из многих

гуглите «гонка данных» и т.п...

RTFM: смотреть флажки WUNTRACED и WCONTINUED в man waitpid.

Но тут дело не в статусе. Это хрупкий «механизм взаимодействия», т.е. примерно невозможно добиться надежной/стабильной работы.

В небольшом «кусте» процессов порожденных форками одного экзешника лучше организовать небольшой разделяемый кусок памяти, в котором разместить shared-мьютексы, shared-convarы и shared-barriers.

а второй ему уже посылает SIGCONT и в итоге все стопается

А чего бы всему стопаться, если SIGCONT на не стопнутый процесс ничего не делает и тот продолжает работать?

Как узнать статус процесса

Статус узнать можно, но гонка всё равно останется. Поэтому лучше просто перепиши приложение по-человечески - надёжных средств синхронизации придумано навалом. Объясни зачем тебе эта ерунда с сигналами?

В небольшом «кусте» процессов порожденных форками одного экзешника лучше организовать небольшой разделяемый кусок памяти, в котором разместить shared-мьютексы, shared-convarы и shared-barriers.

Задача в универе такова, что можно использовать только сигналы.

А чего бы всему стопаться, если SIGCONT на не стопнутый процесс ничего не делает и тот продолжает работать?

Код двух дочерних процессов имеет следующий вид:

/* child1 */
for (;;)
{
    raise(SIGSTOP);
    /* TO DO */
    kill(child2, SIGCONT);
}
/* child2 */
for (;;)
{
    raise(SIGSTOP);
    /* TO DO */
    kill(child1, SIGCONT);
}

Откуда видно, что если один из дочерних процессов пошлет другому SIGCONT, пока второй не успеет послать самому себе SIGSTOP, то все зависнет.

Ох. Этот шедевр может занять почётное место в любой коллекции wtf-кода.