Re: libpthreads,libmpeg3 -> windows

From

Valentin Nechayev ()

To

Boris Rudakov ()

Date

2003-06-08T23:51:16Z

Area

CARBON.COPY

 * Forwarded from area 'RU.UNIX.PROG'
From: Valentin Nechayev <netch@segfault.kiev.ua>


>>> Boris Rudakov wrote:

 VN>> Кто им виноват, что тому же gcc не сказали -Wall -W, чтобы проверить
 VN>> на все ошибки?
BR> А я знаю ?!
BR> Виш в чем дело, это писать под юниксы я умею херово и пока что очень мало знаю.
BR> Но вот ИЗ иниксов в Винды я код портирую много и часто. И вот ведь забавная
BR> штука: это не исключение, это ПРАВИЛО что линуксоидные сырцы нашпигованы ляпами
BR> по самые яйца !!!

Вполне возможно. Когда идёт массовая разработка на энтузиазме и желании
увековечить своё имя, общий уровень качества разработки крайне низок.
Это уже специфика ниши. Постепенно эта ситуация выпрямляется.

BR> Я не линуксоид, я не пользуюсь при разработке софта Гнусью, я НЕ ЗНАЮ почему
BR> они не включают "-Wall -W".

Наверно, потому, что оно выключено по умолчанию. ;(

BR> Хороший текст должен содержать ровно НОЛЬ варнингов.

Это преувеличение.
Какой-то кусок кода может быть выключен, например, комбинацией определений
времён компиляции. Есть и менее тривиальные случаи.

 VN>> Если регулируем, то и MSVC (это его ты назвал "Инвижуал"? Или Intel?)
BR> Конечно же - Мелкософтовский MSVC :):):):):)

А откуда приставка "Ин"?

 VN>> полечит ситуацию - у него тоже есть высокие уровни warning'ов, надо их
 VN>> лишь включить.
BR> Их надо НЕ ВЫКЛЮЧАТЬ :):):):)

Для gcc их надо включить.

[...............................................................]

 DS>> Следовательно, можно совершенно спокойно писать в рамках posix и не
 DS>> париться.
BR> А вот это - не факт.
BR> У меня осталось устойчивое воспоминание что пробовавшие posix subsystem ругали
BR> ее почем зря. Чччччерт, надо уточнить за что. Самому дико интересно стало :):)

Хехех. Посмотрел бы я на хотя бы терминалы в этой подсистеме. Смех и грех,
скорее всего.

BR> КСТА: этот вопрос я очень хочу провентиллировать (все время руки не доходят
BR> написать тестовую программку и посмотреть что выйдет): как в юниксах (для
BR> простоты возьмем платформу i386) организована обработка исключений ?

Никак, за отсутствием оной.

 BR>>> форка (который есть неконцептуальное зло и пережиток)
 DS>>      Обоснуй.
BR> Лехко !!!
BR> Форком юзаются чтобы распараллелить вычисления - один процесс побег по одной
BR> ветке, а его клон ломанулся по другой. В момент форкания создается ИДЕНТИЧНЫЙ
BR> клон - копия памяти, дубликаты хендлов. НАХЕРА ?????

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

BR> Реально ведь склонированному процессу ВСЕГО ЭТОГО - НЕ НУЖНО, ему нужно только
BR> несколько хендлов (либо за которые теперь отвечает он, либо те что нужны для
BR> взаимодействия с родителем) и буквально несколько переменных, в которых
BR> находится набор его прикладных данных.

У тебя странные представления о том, что нужно дочернему процессу.
Возможно, они годятся для какой-то подгруппы задач. Но явно не для всех.
Есть случаи когда после fork() сразу идёт exec(), есть случаи слабосвязанного,
но того же процесса, есть случаи сильносвязанного процесса. Под общий аршин
их не подогнать.

BR> Ну и плюсом к этому безобразию еще один disadvantage - усложняется
BR> взаимодействие между родителем и клоном. IPC надо.

Это ты с ветками сравниваешь. Это отдельный вопрос - сравнение форкнутых
процессов с ветками. Кстати, здешний FAQ appendix 1 читал? Нет? Зря:

=== cut ===
2. Сервер может использовать несколько процессов, каждый из которых
обслуживает собственного клиента:
  Плюсы:
    + Простая модель данных
    + Скалируется с ростом числа процессоров.
    + Ошибки в одном процессе не приводят к отказу в
    обслуживании остальных клиентов.
  Минусы:
    - Процесс - это достаточно тяжелый объект OS, поэтому
      метод неприменим при большом количестве одновременно
      работающих клиентов (больше нескольких десятков или
      сотен).
=== end cut ===

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

BR> Не, дерьмо это. Мое глубочайшее убеждение: форки - неконцептуальное, форки -
BR> зло и пережиток. Параллелизм должен базироваться на нитях.

На самом деле тебя сильно клонит в эту сторону тяжеловесность процессов
на NT. Это не везде так. Старые линуксовые процессы, например, по затрате
ресурсов практически идентичны веткам.


-netch-
--- ifmail v.2.15dev5
 * Origin: Dark side of coredump (2:5020/400)