Глубины Инди

← →
iZEN © (2006-02-27 00:05) [40]

Интересно, авторы уже изобрели NIO API или только подбираются к нему? :)

← →
iZEN © (2006-02-27 00:33) [41]

Критика

3.23. Кодовые потоки (thread)
Кодовые потоки – это метод выполнения программы. Большинство программ имеют только один поток. Тем не менее, дополнительные потоки могут быть созданы для выполнения параллельных вычислений.

А почему бы не назвать вещи своими именами?
«Нити» - общеупотребимый термин в данном случае.

3.24. Fork
Unix до сих пор не имеет поддержки потоков. Вместо этого, Unix использует ветвление (forking). С потоками, каждая отдельная строка выполнения исполняется, но она существует в том же самом процессе, как и другие потоки и в том же адресном пространстве. При разветвлении каждый процесс должен сам себя разделять. Создается новый процесс и все хендлы (handles) передаются ему.

Вот уж глупости.
UNIX имеет разные нити. UNIX может поддерживать как "легковесные" реализации (pthreads), так и "тяжеловесные" на основе процессов (c-threads). Всё зависит от используемого ядра и операционного окружения. Solaris, например, может свободно "жонглировать" разными библиотеками реализации нитей в реальном времени, незаметно для пользователя, в угоду большей эффективности исполнения.

3.27. Сетевой порядок байт
Различные компьютерные системы хранят числовые данные в различном порядке. Некоторые компьютеры хранят числа, начиная с самого наименее значимого байта (LSB), тогда как другие с наиболее значимого байта (MSB). В случае сети, не всегда известно, какой компьютер используется на другой стороне. Для решения этой проблемы был принят стандартный порядок байт для записи и передачи по сети, названый сетевой порядок байт. Сетевой порядок байт это фиксированный порядок байт, который должен использоваться в приложении при передаче двоичных чисел.

Обо всём и совершенно ни о чём.
Сетевой порядок байтов чётко определён для каждого из протоколов обмена. Т.н. network byte order для двоичных чисел: сначала старший, потом младший байт. Об этом конкретно вообще ни слова. Странно.

Продолжение критики книги воспоследует после некоторого перерыва.

← →
Anatoly Podgoretsky © (2006-02-27 00:40) [42]

Да много там ляпов у авторов и я наверно некоторые добавил своим переводом.
Они хотели написать книгу про Инди, а написали про Интернет, ну и не убереглись.

← →
Anatoly Podgoretsky © (2006-02-27 00:41) [43]

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

← →
iZEN © (2006-02-27 01:10) [44]

Так...пошла критика технологии

4.1. Путь Indy ... Сервера Indy создают новый поток для каждого клиентского соединения. Сервера Indy создают слушающий поток, который изолирован от главного кодового потока программы. Слушающий поток случает входящие клиентские запросы. Для каждого клиента, которому отвечают, создается новый поток для его обслуживания. Необходимые события возбуждаются в контексте данного потока.

Так недалеко до DoS. Интересно, авторам известна данная аббревиатура? Похоже что нет. Вот когда несколько тысяч крэкеров ринутся на открытое серверное соединение Indy, и она начнёт для каждого создавать отдельную нить обработки..., угадайте, что произойдёт? :)))

Ну ё-маё, thread-pool трудно было придумать?

4.2. Методология Indy Если вы уже работали с другими сокетными компонентами, то просто забудьте все, что вы знали. Это будет вам только мешать и вы будете делать ложные предпосылки.

Ага. СЧАЗ. :)))

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

Не согласен. Есть разные библиотеки и реализации TCP/UDP/IP-стэков. Одни работают с блокирующими методами установления соединения, другие — с неблокирующими. По-моему, здесь поровну и тех, и других. Кому что нравится и удобнее, то и использует.

... Например, с другими компонентами, когда вы делаете соединения, то вы должны ожидать событие соединения или крутить цикл ожидания, пока свойство, ухаживающие факт соединение не будет установлено. С Indy, вы просто вызываете метод Connect и просто ждете возврата из него. Если соединение будет успешное, то будет возврат из метода по окончанию соединения. Если же соединение не произойдет, то будет возбуждено исключение.

Очень странное предубеждение авторов против неблокирующего режима соединения.

По-мне, так, неблокирующее — более простое, нежели блокирующее. Не нужно изобретать собственные нити передачи управления, организовывать handler"s-pool, ведь всё уже организовано в callback-методах.

4.6. Потоки Для реализации функциональности используются потоки. Indy очень интенсивно использует потоки для реализации серверов, потоки так же используются и в клиентах. неблокирующие сокеты также могут использовать потоки, но они требуют некоторой дополнительной обработки и их преимущества теряются по сравнению блокирующих сокетов.

Ещё раз: во всей книге замените слово «ПОТОКИ» на «НИТИ», если это не относится к потокам данных (Streams), а относится к потокам исполнения кода (Threads).

Продолжение критики книги (и технологии) воспоследует после некоторого перерыва.

← →
iZEN © (2006-02-27 01:31) [45]

Грамматика и орфография

стр. 28
Когда API Unix-сокетов был портирован в Windows, то ему дали имя Winsock.

API — муж.род, поскольку: Прикладной Интерфейс Программирования.

Windows 3.x не могла распараллеливаться и плохо поддерживалла многозадачность. Windows 3.1 также не имелла поддержки потоков.

Windows — жен.род, поскольку: Операционная Система.

Конечно же, «Юникс» везде заменить на «UNIX» (все буквы заглавные, поскольку это семейство ОС, а не какая-то конкретная система).

← →
iZEN © (2006-02-27 01:36) [46]

Windows 3.x не могла распараллеливаться и плохо поддерживала многозадачность. Windows 3.1 также не имела поддержки потоков.
Н-да, опечатки исправил.

По сути. В Windows 3.1 была реализована кооперативная многозадачность.

← →
unknown © (2006-02-27 01:51) [47]

> iZEN © (27.02.06 01:10) [44]
> Ну ё-маё, thread-pool трудно было придумать?

Так ведь есть же TIdThreadMgrDefault и TIdThreadMgrPool

← →
@BraIN © (2006-02-27 03:20) [48]

Правки-правки..
Так и до написания новой книги не далеко ;)

> Ещё раз: во всей книге замените слово «ПОТОКИ» на «НИТИ»,
> если это не относится к потокам данных (Streams), а относится
> к потокам исполнения кода (Threads).
>

"Потоки" - широко распространенный термин с указанным смыслом, не надо понапрасну шуметь.

unknown © (27.02.06 01:51) [47],
да, этот менеджер упомянут одним абзацем. Авторы походу дела его разработали. :))
Под конец описания книжка приобретает вполне читабельный вид, если не учитывать кучу опечаток и грамматических ошибок. Даже критиковать нечего.

calm © (27.02.06 09:27) [49],
Термин «ПОТОКИ» в русскоязычной литературе до недавнего времени использовался в двух контекстах: потоки данных и потоки исполнения. В последнее время популярен термин «НИТИ» в отношении потоков исполнения, так как не требует уточнения контекста и с английского переводится именно так, а не иначе. Кстати, термин «НИТИ» используется в книжке Ю.Вахалии "UNIX изнутри".

Насчёт неблокирующих соединений закончу свою мысль: неблокирующие соединения более высокоуровневые абстракции. Обычно, на основе блокирующих соединений строят неблокирующие событийно-ориентированные "коннекторы", а не наоборот.

Глубины Инди Найти похожие ветки