>Боюсь даже подумать, куда они в етом случае едят попкорн.

разумеется через ж..

в смысле сперва делалось send(..) а затем все висело в recv(...)?

я никак не пойму, как такое возможно.

если это фича ядра, то линупс кагбэ непоправимое решето.

спасибо автору за новость. В lkml периодически происходят очень интересные вещи, а самому следить за таким большим списком рассылки некогда. на kernelnewbies такое не освещают :)

>ИМХО, Кокс прав..

Линус тоже прав.
На сколько я понимаю, само по себе старое поведение не противоречит posix, противоречит использование данной недокументированной фичи. Но с другой стороны, эту фичу юзают уже полтора десятка лет, и фиг знает где что сейчас может вылезти.
Конечно, юзерспейс-приложения надо постепенно исправлять.

>>о! кстате знакомая ситуация!:

Тут примерно похожая картина: оба посылают данные, после этого сразу делают close(). Первый получает не все данные, после чего ловит close() - думает что дочерний процесс завершился и то, что находится еще в буфере на отправку не отсылает (процесс-то якобы завершился) и ждет остальные данные. В это время на другой стороне: получено не все данные и после этого close() - сторона продолжает ждать данные, а в то же время другая сторона тоже ждет ответа. И усе, оба процесса в дедлоке. Вот такая фигня и может случиться со старым TTY.

Ну Линус адекват, заботится не о фантастическом соответствии стандартам, а о том, что все это не ушло под откос со всем юзерспейсом. Конечно, нельзя ломать то, на что опирались 17 лет.

> нельзя сразу ломать то, на что опирались 17 лет.

fxd

>>Ну Линус адекват, заботится не о фантастическом соответствии стандартам, а о том, что все это не ушло под откос со всем юзерспейсом. Конечно, нельзя ломать то, на что опирались 17 лет.

Оба правы по-своему. Лишь ядро не рвануло из-за этой заварушки :)

А мне еще интересно, как они решат этот вопрос?

не понял, может все вокруг такие умные, а я один тупой, но как ОБЕ стороны могут ждать данных, если хотя бы одна закрыла дескриптор?

>Тут примерно похожая картина: оба посылают данные, после этого сразу делают close(). Первый получает не все данные, после чего ловит close() - думает что дочерний процесс завершился и то, что находится еще в буфере на отправку не отсылает (процесс-то якобы завершился) и ждет остальные данные. В это время на другой стороне: получено не все данные и после этого close() - сторона продолжает ждать данные, а в то же время другая сторона тоже ждет ответа.

Я в последнее время к poll/select пристрастился. Более трудоемко, но наколько же меньше разных мелких кариесов!

может быть просто надо реализовать нормально терминал, а не заплатками его заклеивать?

терминал, как и сокет и пайп - последовательный поток.

выделим ему кольцевые буфера, в них будем хранить что-то типа uint16_t portion_size;//>0 - data, <=0 - message char content[n]; выравненное на границу 2байт.

всё что туда засовываем - сигналы ли вроде SIGHUP, сообщения о закрытии - всё это данные. тогда программа не увидит закрытия другой стороны до окончания приёма данных, а если программа А начала посылать что-то программе Б, которая сама закрыла вход, должна быть ошибка, которую надо обработать в программе А, а не править ведро.

а пример какой то глючный: если кто-то "ловит" close() первее чем принял предшествующие ему данные - это баг. а если "на другой стороне чего-то ждут" после закрытия дескриптора, то проблема не в ведре, а в руках кодера.

>>не понял, может все вокруг такие умные, а я один тупой, но как ОБЕ стороны могут ждать данных, если хотя бы одна закрыла дескриптор?

Обе стороны ОДНОВРЕМЕННО закрывают дескриторы, но фишка в том, что эти дескрипторы могут прийти в середине данных, поэтому сторона будет ждать остатка данных, которой не придет из-за того, что другая сторона тоже получила дескриптор и прекратила отправку данных.

речь идёт о каком то секретном API для работы с tty, о котором я не знаю?

если речь о том, что последовательно идущие через терминал события десериализуются - то это баг. не должно приходить оповещение о закрытии раньше чем данные, переданные до закрытия. у нас ПОСЛЕДОВАТЕЛЬНЫЙ ТЕРМИНАЛ или что?

>>а пример какой то глючный: если кто-то "ловит" close() первее чем принял предшествующие ему данные - это баг.

Там конкретно не close() ловится, а SIGCLD. Фишка в том, что TTY - это не просто последовательный поток. Где-то в середине линии происходит обработка данных. Данные отправляются в очередь и их обработка там завершается при получении close(). Но никто не гарантирует, что данные придут раньше, чем сигнал SIGCLD. Из-за этого и весь сыр-бор разгорелся, именно из-за итого емакс и сломался.

>>а если "на другой стороне чего-то ждут" после закрытия дескриптора, то проблема не в ведре, а в руках кодера.

Это проблема приложений, которые были заточены под старое поведение.

>>если речь о том, что последовательно идущие через терминал события десериализуются - то это баг. не должно приходить оповещение о закрытии раньше чем данные, переданные до закрытия. у нас ПОСЛЕДОВАТЕЛЬНЫЙ ТЕРМИНАЛ или что?

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

это что называется must be fixed в другом месте.

если процесс породил кого-то, и ждёт sigchld - он должен изначально уметь обработать ситуацию, когда сигнал придёт раньше. например, он однопоточный, и спал, когда процесс-раб закрылся. проснувшись главный процесс ессно увидит перед собой сигнал и побежит его обрабатывать первым, а только потом вернётся к выполнению "нормальных" команд. это нормальное поведение.

я правильно понимаю, что "старые программы" были просто в массово порядке написаны через жопу?

>>если прикладуха хочет ходить на ушах - ядро не должно мешать ей это делать.

Ну что за ерунда! Например:

Вот я хочу двунаправленный обмен данными через pipe. Моя программа работает, но иногда виснет! Надо написать Трвальдсу, что бы он поправил ядро, что бы моя программа не попадала в дедлок!

Вот такой вот бред получается.

>>я правильно понимаю, что "старые программы" были просто в массово порядке написаны через жопу?

Да, именно проблема в этом. Для примера, что произошло в емаксе: емакс запускает процесс компиляции и ждет его окончания. И тут емаксу приходит SIGCHLD и он думает, что раз процесс завершился, то значит данные готовы и начинает читать входной поток - а там пусто и прога не понимает, что произошло. А данные просто еще не успели дойти до емакса.

Про время это точно. Я думаю ща пар повыпускают и начнут разруливть.

> Линус прав как всегда.

Это что же? Шумахера теперь уволят, а на его место Торвальдса?

> вот как уйдут Алан Кох с Тедом Тсо от него к Таненбауму... :D

Пусть лучше к Столлману идет Hurd допиливать J

В команде бородачей прибудет J

Ждем howto как пропатчить kde4 под linux

Нельзя же ради одной софтины ядро костылями пичкать.

\trollmode{Быть может, это КДЕ завтра сдохнет и все на гном перейдут. А костыль останется. К тому же, в кедах и без того больше половины программ не работает как надо, им не страшно.}

кадеешники форкнут ядро :)

Консоль в ядре давно пора чинить, там конь не валялся в плане приведения всей подсистемы в божеский вид. Одна из самых запущеных его частей.

Пруфлинк в студию.

>Раненых с нейтральной полосы вытаскивали, да. Но в то же время во время войны бросали без помощи группировки размером до 300 тысяч человек.

Пруфлинк или не было.

>>>Раненых с нейтральной полосы вытаскивали, да. Но в то же время во время войны бросали без помощи группировки размером до 300 тысяч человек.

>>Пруфлинк или не было.

man Киевская операция 1941 года

Ничего они не форкнут, Кюте3 же бросили. У кде другая стратегия - облепить все костылями, а потом выбросить(пример: кде3). Именно поэтому гнать их нужно подальше от ядра в данном случае и в других случаях тоже.

Дык никто ж не запретит, будут мантейнить подсистему костылей.

> man Киевская операция 1941 года

а там не 600 ли тысяч было?

Тем временем, на опёнке:

"В центре событий оказалась программа kdesu – реализация утилиты su для графического окружения KDE, которая перестала работать после внесенных Аланом патчей в файл pty.c. На одну из причин такого поведения проливает свет следующая цитата: «Из-за того, что некоторые реализации su (например, Red Hat) не хотят брать пароль со стандартного ввода (stdin), KDE su создает собственную пару pty/tty и запускает на исполнение su со связанными с tty файловыми дескрипторами»."

Фоменко?

>>>>Раненых с нейтральной полосы вытаскивали, да. Но в то же время во время войны бросали без помощи группировки размером до 300 тысяч человек.

>>>Пруфлинк или не было.

>man Киевская операция 1941 года

Армия США не принимала участия в Киевской операции 1941 года! Учите полит.информацию.

>>Ничего они не форкнут, Кюте3 же бросили. У кде другая стратегия - облепить все костылями, а потом выбросить(пример: кде3). Именно поэтому гнать их нужно подальше от ядра в данном случае и в других случаях тоже.

Уфф.. напомнил мне про кдешный кикер... Когда в его исходники посмотрел, мне потом неделю кошмары снились. Подсистема TTY отдыхает.

> Когда в его исходники посмотрел
С какой целью интересовался?

>>а там не 600 ли тысяч было?

Даже почти 700...

>>С какой целью интересовался?

Было интересно, действительно ли они встроили автоматический перезапуск кикера после его очередного креша прямо в него - думал, это делает какой-то демон. Ан нет, оказалось и вправду он умеет сам перезапускаться после крешей, + там еще куча костылей поприкручена, что самая ужасная работа у кедерастов в то время была чинить кикер, людей туда как на каторгу отправляли :)

>>Армия США не принимала участия в Киевской операции 1941 года! Учите полит.информацию.

А, ну если разговор про САСШ - то да, я тоже не помню, чтобы они 300К народу кинули.

!!!>взять из истории любой пример, когда АМЕРИКАНСКАЯ АРМИЯ (снабжаемая американским народом) проводила крупные операции с целью освобождения из плена единственного солдата.

>>>Армия США не принимала участия в Киевской операции 1941 года! Учите полит.информацию.

>А, ну если разговор про САСШ

Сюрприз!

>>любой пример

Можно было растолковать, что САСШ была взята для примера.

> кадеешники форкнут ядро :)

и kernel наконец-таки станет Kernel?

>Обе стороны ОДНОВРЕМЕННО закрывают дескриторы, но фишка в том, что эти дескрипторы могут прийти в середине данных, поэтому сторона будет ждать остатка данных, которой не придет из-за того, что другая сторона тоже получила дескриптор и прекратила отправку данных.

Бррр. Ты какую-то муть написал. Какие "дескрипторы в середине данных"?

Что было на самом деле: видимо, раньше close для дескриптора, связанного с терминалом, убеждался, что данные, связанные с закрываемом дескрипторе были успешно посланы. Это может привести к такой проблеме: два процесса, связанные псевдотерминалом, одновременно что-то пишут и закрывают файловые дескрипторы. close ждет, что данные будут доставлены, но т. к. читать на другом конце некому, процессы уходят в себя всерьез и надолго.

Что изменил Кокс: close перестал дожидаться приема данных другой стороной => close завершается раньше, чем до читающей стороны доходят данные; читающая сторона ловит SIGCHILD и не пытается ничего дочитывать с pty.

С одной стороны Кокс прав, описанной им блокировки не должно быть. С другой стороны, как теперь определить, что мы вычитали весь вывод дочернего процесса с pty? После SIGCHILD там может быть еще что-то, а может и не быть.

Это пруфлинк того, что в кдесу есть ошибка. О чем кстати и говорилось в ссылке выше на lwn.net

> Пруфлинк или не было.

А можно пруфлинк на крупную операцию, проведенную армией США ради освобождения единственного солдата?

Ну ненадо... этого :-))

>> Пруфлинк или не было.

> А можно пруфлинк на крупную операцию, проведенную армией США ради освобождения единственного солдата?

Дык =)

http://www.imdb.com/title/tt0120815/

>>Бррр. Ты какую-то муть написал. Какие "дескрипторы в середине данных"?

Не дескрипторы, конечно, а SIGCHLD :)

Действие "Компиляция". Участники: emacs (отец), gcc (блудный сын), pty (телеграф), заботливый Боженька (linux kernel)

* emacs рожает сына (gcc)
* Московия
emacs: Сыну, поди скомпилируй эту хрень. Фотоотчет высылай через pty.
gcc: Понял, батя. Компилю!
* gcc уходит в замкадье на компиляцию и пишет оттуда
gcc: Ботва в строке 12
* Московия
pty: Вам молния: "Ботва в строке 12". Распишитесь!
emacs: Хренотень какая-то :(
* Замкадье
gcc: Ботва в строке 55.
* gcc умирает с чувством выполненного долга
* Московия
kernel: emacs, твой сыну помер.
emacs: Горе-то какое, сыну помер! Пойду хоть поправлю ошибку в строке 12.
* emacs уходит с телеграфа
pty: Вам молния: "Ботва в строке 55". Распишитесь! Эй! Да мне похер, ты же письма ждал, не я.

Ой как ТОЛСТО!

Такими штуками только Израиль балуется