Вредный GDB...

Вообще-то сообщение мультисессионное, само использование
thread к нему не ведет. Отлаживаю программы подобного типа
почти без проблем. Тут скорее надо разбираться с вызовом программ,
т.е. искать fork/exec/system и т.п. Сообщение может быть
именно от порожденных новых процессов, ну а папаша ждет.

Да нет у меня там ни одного fork/exec/system...

stty -tostop
gdb ./myprogram
...

А зацикливаться дисциплина не зацикливается, а после отправки TTOU делает ERESTARTSYS в надежде на то, что ты его корректно отработаешь (если ты его не обработаешь, то просто заснешь и после CONT начнешь по новой).

ЧЁ?? %))))))))

That's a modern joke... are you unaware? ;)

А... понятно, спасибо. Только вот теперь неясно, какой же процесс делается фоновым? Я так понимаяю. если фоновый процесс пытается записать в терминал, его группе и посылается SIGTTOU. GDB делает фоновым отлаживаемый процесс?

Честно говоря, я даже не знаю.

У нас в userspace работает один человек - он как-то столкнулся с такой лажей. Мне самому интересно чей это глюк - GDB или LinuxThreads/NPTL, но руки пока не дошли разобраться... надо будет после НГ заняться.

По поводу SIGTTOU - все так. Логика реализуется в src/linux/drivers/char/tty_io.c: tty_check_change:
1) разрешается писать в чужой терминал
2) разрешается писать в свой терминал, если твоя группа - активная
3) разрешается писать, если игнорируешь SIGTTOU
4) если все выше не выполнено и твоя группа - orphaned, то возвращается EIO
5) иначе посылается SIGTTOU твоей группе (группе текущего процесса) и EIP для userspace уменьшается на 2, что будет соотв. повторному вызову write после обработки сигнала (если ты его не ловишь - то заснешь).

Я думаю, что проблема в том, что gdb для себя и процесса создается разные группы и когда ты отлаживаешь одну нить - остальные не тормозятся, что приводит к тому, что активная группа - содержащая GDB, а остальные нити получают SIGTTOU при попытке что-либо вывести. Это на уровне предположения, так что могу сильно ошибаться ...

Если без GDB это не проявляетя, то это исключительно проблемы GDB из-за которых не стоит переживать. ;)

Рекомендую попробовать выдать:
ps -o pid,ppid,pgrp,sid,comm -u user...
В моем случае получаем:
PID PPID PGRP SID COMMAND
12423 11250 12423 11250 gdb
12604 12423 12604 11250 srv
12622 12604 12604 11250 srv
12623 12622 12604 11250 srv
12624 12622 12604 11250 srv
Из чего следует, что gdb действительно запустил мой пример
в новой группе и повод для SIGTTOU имеется.

Обычно stty показывает -tostop:
$ stty -a
speed 38400 baud; rows 54; columns 165; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke

Однако, если запускать всякие забавные программы типа mc получим:
$ stty -a
speed 38400 baud; rows 54; columns 165; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = <undef>; eol2 = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V;
flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase tostop -echoprt echoctl echoke
Видно, что mc всабачил эти параметры для нового псевдотерминала.

Что будет если стартовать gdb из под mc (ну или параметр добавить):
gdb srv
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
...
(gdb) run ...
Starting program: srv
[New Thread 1024 (LWP 12701)]
[1]+ Stopped gdb srv
bash-2.05$

Я ожидал последствий типа Ваших, но это и вовсе перебор, у меня
и сам gdb стопанулся и ждал fg.
Не используете ли Вы mc? Нет ли в программе ioctl или каких-то
средств управления терминалом?