Обнаружена D.o.S. для Tux-2.1.0-2

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

А ты описываешь вариант, удобный если набить весь текст, а потом один раз дернуть спеллчекер. Да и твои дальнейшие действия после fork + exec не совсем ясны.

P.S. Я не против форков. И под юнихами я в зависимости от ситуации использую или fork или pthread_create.

>(v)fork + exec.
>Немного подумав, поймешь, что иначе и не получится.
>Можешь, конечно, придумать обертку к этой парочке, назвать ее
>CreateProcess, выкинуть fork, забыть о наследовании процессов ...

Данный вопрос был о виндах :)
Наследование есть, но ограниченное. Дескрипторы можно наследовать.
А если нужен IPC, то тут что в виндах, что в юнихах придется использовать некоторые дополнительные средства (шареная память и т.д.)

2Havoc (*) (2001-11-15 11:59:08.0):
> Смотри, ты набрал еще парочку слов. Ты опять хочешь форкаться?
Зачем?
> Имхо, лучше, чтобы тут работала нитка с низким приоритетом и подхватывала
> измененный текст.
Ок, отличный пример того, когда нитки НЕ нужны, вернее, ВРЕДНЫ как
концепция. Поэтому позволю себе быть многословным :)

Итак, возможны 2 решения.
1. Синхронная проверка. Т.е. результат нажатия очередной клавиши передается
функции, осуществляюшей проверку.
2. Асинхронная проверка "в фоне" - некий внешний процесс осуществляет проверку
каждого набранного слова независимо от редактора и возвращает результат
редактору.

ВСЕ!
Другого не дано.

Первый вариант ты не обсуждаешь - слишком, типа, "не научно"! Остается второй.

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

Люди, начинавшие с win32, почему-то уверены, что существует еще и третья
возможность. Типа, запустить нитку со спеллчекером.

Но это всего лишь решение 1) с автоматическим расшариванием данных. Что в
данном случае не приносит никаких дивидендов: мне всего-то надо от редактора
передать спеллчекеру очередное слово, а обратно получить булево значение.
"Тяжесть" процесса в этом примере не играет НИ МАЛЕЙШЕЙ роли, поскольку в
любом случае спеллчекер стартанет только один раз, и сделает это быстрее,
чем юзер моргнет.

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

И все это только потому, что создатели win32 не предусмотрели такое
элементарное средство как форк (только не надо мне впаривать про
позикс-подсистему).

Sorry,

s'/Но это всего лишь решение 1)/Но это всего лишь решение 2)/'

Для второго варианта получается надо опять писать свой спеллчекер.
С внешним ispell так не прокатит.

Про тяжесть в данном случае согласен.
А про то, что нитка может покорежить память, так процесс тоже может шаренную память покорежить. И опять может грохнуться главная аппликуха. Всякие аля-улю нужно предусматривать в любом случае.
Т.е. ты одноднозначно считаешь, что нитки не нужны?

P.S. Заметь, я не считаю, что fork не нужен.
А про Win32, тут пофиг, мне приходится под разные оси писать.
Имхо, зацикливаться на одной оси не есть хорошо.
Может завтра за макинтош сяду :)

> С внешним ispell так не прокатит.
екзеком грузишься, и все прокатит. Под вторым вариантом я имел в виду
параллельное выполнение двух процессов, даже если второй процесс не
называть процессом :) Просто с внешнего файла грузиться дольше, чем
форкаться, но в данном случае как раз по барабану. Чистый форк нужен
для частого запуска дочек, типа, сервер.

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

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

А нитка запросто покорежит указатель толстого процесса и - аля-улю:(
Даже проще - нитка грохнется, и система "заодно" прикроет и толстый
процесс.

> Т.е. ты одноднозначно считаешь, что нитки не нужны?
Почти.

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

Собственно, это не я придумал. До начала M$-экспансии это было
общепринятой точкой зрения. Проект Малтикс в свое время "не пошел"
во многом благодаря отсутствию четко выраженной концепции процесса.
Дело кончилось возникновением Юникса, и один из главных уроков был:
процессы не должны разделять данные. Это то же самое, что и использование
goto: (почти) всякий раз, когда тебе "хочется" воткнуть в свою программу
goto, ты можешь, подумав, развести потоки управления оптимальнее.

> Заметь, я не считаю, что fork не нужен.
Однако, "последняя серия" нашего спора возникла именно из-за того,
что ты высмеял форк, заклеймив его как "дедовский" метод :)

> Имхо, зацикливаться на одной оси не есть хорошо.
Ну, тут я согласен.
Действительно, специфика win32 такова, что требует несколько иного способа
мышления при программировании. В частности, нитки там - не роскошь, а
естественный способ выполнения асинхронных операций.

Но win32 - единственный подобный API. Даже в Солярке такого злоупотребления
нитями нет. Конечно, я понимаю, что подавляющее большинство программ
сегодня пишется для win32, и меня просто бесит :) то, что этот ... весьма
специфичный способ мышления стал обшепринятым. Конечно, это - мои личные
комплексы, но, когда win32 загнется, то целое покления программистов окажется
"потерянным".

Я вспоминаю, как в конце 70-х годов, когда я был школьником и нас учили
Фортрану, периодически возникали религиозные баталии на тему "Фортран vs.
Алгол". Аргументы были таковы: "90% программ в мире пишутся на Фортране,
и, когда вы закончите школу, ничего, кроме Фортрана, просто не останется!"
Ничего не напоминает?

Зато теперь большинство моих коллег - не программистов просто не в состоянии
одолеть иной язык. Слишком далеки базовые принципы программирования,
навязываемые четвертым Фортраном, от того, что сейчас считается "хорошим
тоном"!

> А нитка запросто покорежит указатель толстого процесса и - аля-улю:(
Ну молотком и череп проломить можно :)

>В частности, нитки там - не роскошь, а
>естественный способ выполнения асинхронных операций.

Кстати, не единственный.

>Однако, "последняя серия" нашего спора возникла именно из-за того,
>что ты высмеял форк, заклеймив его как "дедовский" метод :)

Не совсем. Основная мысль в том, чтобы не юзать тупо fork, а все таки решить, что в данном конкретном случае оптимальнее.

>Конечно, это - мои личные комплексы, но, когда win32 загнется, то
>целое покления программистов окажется "потерянным".

Ну что загнется раньше, это еще неизвестно. Но вот тебе реальный пример. Мой коллега программист до недавнего времени юнихов в глаза не видел. И ничего, поставил себе FreeBSD, порылся в инете, сумел более менее ее настроить, пишет под нее проги (не в кайликсе :)
Имхо, для программиста, а не рисователя кнопочек, перейти под другую платформу не проблема. Другой коллега сейчас занят портированием софта под маки. Мы с ним наблюдали, как легко укладывается MacOS 9.1 элементарным buffer overflow. Конечно, поначалу тяжело, но ничего сверхтрудного в этом нет.

Похоже, что данная дискуссия кроме нас больше никому не интересна, поэтому, если есть желание, давай в мыло: havoc@idea.org.ua

2Havoc (*) (2001-11-19 16:10:07.0):
> Похоже, что данная дискуссия кроме нас больше никому не интересна, поэтому, если есть
> желание, давай в мыло:
Ok, появлюсь на днях.

Все ж, комментну кусочек публично:
> Но вот тебе реальный пример. ... юнихов в глаза не видел ... поставил себе FreeBSD ...
> пишет под нее проги
Легко перейти с win32 на позикс, если мозги еще не заржавели :), единственная проблема -
непривычно поначалу, но ГОРАЗДО (IMHO) все логичнее. Наоборот - сложнее.
Апологеты win32 уверяют, что это из-за того, что их любимый АПИ значительно богаче,
я (и многие другие, являющиеся для меня авторитетами) считаю, что богатство
("фичастость") win32 проистекает из-за нелогичности/эклектичности данного АПИ.

Дык, каждый кулик свое болото хвалит :)