Что-то у меня ощущение, что вы путаете "дисплеи" в смысле X Window и виртуальные консоли, у которых нумерация своя.

В принципе любой X-сервер может быть запущен на любой виртуальной консоли и при этом иметь любой номер дисплея, т.е. номер вирт.консоли никак не связан с номером дисплея. На 7-й консоли у вас, видимо, штатный X-сервер, запускаемый вашим дистрибутивом линукса или что у вас там. Если так, то, скорее всего, тот X-сервер, который запускаете вы (вручную, как 1-й дисплей) берёт себе 8-ю консоль, так что переключаться на него (с любой из текстовых консолей) следует по Alt-F8. Непонятно только, почему это не происходит само собой. Но вообще это всё напоминает "диагноз по фотографии", сложно сказать, что там у вас такое происходит, не видя машины.

А зачем? Там уже есть 0.0.0.0/0 -> 192.168.14.1, "12я сетка" ни фига не особенная :-)

В новом издании уже исправлено.

Кончайте бредить. exit без подчёркивания — это (документированно!) библиотечная функция, которая, прежде чем завершить программу (то есть обратиться к ядру системы), вызывает ещё все хуки, которые были навешаны на неё функцией atexit (читайте man 3 atexit). Этим пользуется подсистема "стандартного" ввода-вывода, чтобы вытеснить буфера.

_exit с подчёркиванием — это официальное название системного вызова, который, если интересно, в Linux/i386 и FreeBSD/i386 имел номер 1.

К сожалению (именно к сожалению — я бы сказал, к величайшему, поскольку это одно из свидетельств безнадёжной деградации IT-индустрии) "современные" версии "стандартной" библиотеки, поддерживающие (читай -- заточенные) на мультитрединг (относительно которого я говорил, говорю и буду говорить, что применять его недопустимо -- никогда и ни для чего), предпочитают завершать процесс вызовом exit_group, для чего функция с названием _exit там представляет собой не обёртку для соответствующего системного вызова, а простую функцию, которая — ага — вызывает exit_group. Факта существования системного вызова _exit это никак не отменяет. Аналогичная ситуация была, например, с вызовом signal: ядро такой вызов поддерживало, но одноимённая библиотечная функция вместо "своего" вызова обращалась к sigaction. Вот вам, кстати, цитата из man 2 _exit:

In  glibc  up  to version 2.3, the _exit() wrapper function invoked the
kernel system call of the same name.   Since  glibc  2.3,  the  wrapper
function  invokes  exit_group(2),  in  order  to  terminate  all of the
threads in a process.

NB: если НЕ использовать мультитрединг (а я всё-таки надеюсь, что мои читатели не станут пополнять ряды безмозглых макак, которые его применяют), семантика библиотечной функции _exit ничем не отличается от семантики классического системного вызова _exit.

Попробуйте как-нибудь на досуге примонтировать флешку, в соседнем терминале туда зайти, что-то там поделать с файлами, а потом про второй терминал забыть и в первом попытаться флешку отмонтировать.

Hint: будет ошибка "Device busy". Потому что нельзя отмонтировать файловую систему, внутри которой кто-то сидит, то есть в системе существует хотя бы один процесс, текущий каталог которого расположен внутри этой файловой системы.

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

В предисловиях к моим книгам чётко сказано, что переход на *nix и командную строку — это обязательное условие для того, чтобы от книг был хоть какой-то толк. Не хотите переходить на *nix и командную строку — дело ваше, но хотя бы не тратьте время на мои книги, толку не будет всё равно.

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

Именно библиотечная функция exit. На досуге попробуйте вывод программы hello, world перенаправить в файл и осознайте, что если бы там был _exit, ваш файл остался бы пустым.

NB: нуля там никакого нет, откуда вы его взяли? Там просто exit(main()).

В первом случае должен быть именно euid -- effective uid, именно он определяет полномочия.

Во втором должен быть egid, а не euid, как там написано; это уже известная опечатка.

А вот про "парметром" -- спасибо большое, и корректор это прощёлкал, и сам я проглядел, хотя совсем недавно редактировал этот кусочек.

Абсолютно верно, спасибо! Вовремя.

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

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

Это вот, случайно, не та же самая проблема?

http://www.stolyarov.info/guestbook/archive/3#comment-2797

Есть такое, уже поймали. Спасибо за внимательность.

Ну так если семафор уже равен нулю, его уменьшить дальше нельзя — в минус уйдёт, а ему запрещено. Там в тексте это вроде написано всё, в этом случае down приводит к блокировке (ради неё, собственно, семафоры и придуманы).

В общем даже понятно, почему. Программа завершается, если видит, что все производители завершились. При этом никто не проверяет, что буфер опустел, и тем более никто не проверяет, нет ли у консьюмеров ещё чего-то "недоскинутого".

Вообще, конечно, вот прямо классический race condition. Надо будет подумать, что с этим можно сделать.

UPD: Всё оказалось ещё проще. В той версии, которая в книжке, консьюмер, если не может сразу заполучить grand_mutex, плюёт на это дело и оставляет информацию в своих локальных переменных. Если он сюда придёт ещё раз, то всё будет хорошо (ибо он тогда всю инфу сразу сольёт), вот только он же может больше сюда и не прийти -- числа кончатся, он повиснет на sem_wait(&buf_full), потом процесс завершится вместе со всеми тредами.

Что называется, хотел один такой (то есть я) продемонстрировать неблокирующий вариант захвата мьютекса, а получилась в итоге полная хрень. Это легко скорректировать, если при наличии локальной инфы опускание семафора тоже сделать неблокирующим, типа, если в основную секцию не пустили, а у меня есть что скинуть, то я хотя бы в секцию по grand_total попробую снова пойти. Но наглядность текста примера после этого упадёт резко, то есть там будет вообще непонятно, что происходит. Так что, видимо, придётся try_lock выкинуть из примера.

Есть, конечно. Ещё как есть. Сейчас посмотрел — стало грустно.

Спасибо за внимательность — на эту ахинею до вас никто внимания не обратил, так что она чуть было не проползла во второе издание.