spf/linux by ~yz

[Dmitry Groshev-2]

Привет жертвам Линуха и пожелания трудовых успехов!

> Можно, но не все. Смотри сюда:
[ ... ]
(http://www.opengroup.org/onlinepubs/7990989775/xsh/sigaction.html)

Бесплатный совет: если задача не в похвастаться знанием английского, а в реализовать обработку сигналов - то читать надо отнюдь не Single UNIX Specification, а сырцы ядра и glibc.

> Я же говорю: архаика. Куча нереентерабельных во время
> прерывания функций живо напоминает незабвенную RT-11.

Изучение вкуса устриц по мануалам (да притом еще и от другой системы) может принести еще не такие "открытия".


-= With best regards, Dmitry Groshev =-


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Yuriy Zhilovets]

Some javascript/style in this post has been disabled (why?)

Andrey Cherezov пишет:

Да я вообще всегда говорил, что Линукс - это DOS на стероидах.
  

Ну это слишком категорично. Ядро там очень изощренное, а вот API никуда не годится: и выглядит старорежимно, и многих полезных вещей нет, и заточен под один и не самый лучший язык. Никогда не понимал, зачем для написания свободной ОС надо было брать за образец именно Юникс?

(если кто помнит историю появления REQUIRE в SPF :).

А я ее и не знал. Идея была сделать нечто в стиле Ребола?

Ю. Жиловец


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Yuriy Zhilovets]

Dmitry Groshev пишет:

>Бесплатный совет: если задача не в похвастаться знанием английского, а в реализовать обработку сигналов - то читать надо отнюдь не Single UNIX Specification, а сырцы ядра и glibc.
>  
>
Ну если это не архаика, копаться в реализации конкретных ядер и
библиотек, как в 60-х годах, то что тогда архаика? Вообще с тех пор
придумали такую вещь как стандарты, а линуксоиды все хакерствуют... Вот
хоть бы и в glibc посмотреть. Функции fstat(a,b), положенной по
стандартам, там нету, зато есть __xfstat(3,a,b) и макрос fstat(a,b).
Вы считаете это хорошим стилем?

>Изучение вкуса устриц по мануалам (да притом еще и от другой системы) может принести еще не такие "открытия".
>  
>
Как это от другой системы? А у меня в книжке "Just for fun" красочно
расписано, как Торвальдс писал ядро по спецификации POSIX. Выходит,
наврали все :-(

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

Ю. Жиловец


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Dmitry Groshev-2]

Приветствую!

Yuriy Zhilovets пишет:
> Ну если это не архаика, копаться в реализации конкретных
> ядер и библиотек, как в 60-х годах, то что тогда архаика?

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

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

> Вот хоть бы и в glibc посмотреть. Функции fstat(a,b),
> положенной по стандартам, там нету, зато есть
> __xfstat(3,a,b) и макрос fstat(a,b).
> Вы считаете это хорошим стилем?

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

> Как это от другой системы? А у меня в книжке "Just for fun"
> красочно расписано, как Торвальдс писал ядро по
> спецификации POSIX. Выходит, наврали все :-(

Дык. Сертифицированных по Single UNIX Specification систем не так много, и Линукс в их число не входит.
И POSIX в Линуксе где-то соблюдается, а где-то нет - и хотя с годами соблюдается всё больше, но и специфических расширений тоже добавляется больше.

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

Лично я спокоен как питон - в вашей гонке моя лошадь не участвует. ;-) Я всего лишь указал на очевидный (для меня) факт, что изучать систему по мануалам == зря терять время.

Хотя любопытно - о каких именно "черных и белых списках" речь?


-= With best regards, Dmitry Groshev =-


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Yuriy Zhilovets]

Some javascript/style in this post has been disabled (why?)

Dmitry Groshev пишет:

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

Не сказал бы, что это такая уж проблема. Реально с несовместимостями между разными версиями Windows я сталкивался раза три-четыре за несколько лет.

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

А зачем мне вообще сдался этот С и его кривые макросы? Какое отношение он имеет к ОС и ее функциям?
И что мне делать, когда завтра выкинут функцию __xfstat  и введут функцию __izvrat ? Срочно перекомпилировать все программы, включая пользовательские?
Ни Перл, ни Питон, кстати, не дают возможности напрямую вызывать функции ОС, а сами компиляторы написаны на С. Так что это сложно назвать решением.

Хотя любопытно - о каких именно "черных и белых списках" речь?
  

Реентерабельных и нереентерабельных функций - которые можно вызывать в обработчике сигнала и которые нельзя.

Ю. Жиловец


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Dmitry Groshev-2]

Приветствую!

Yuriy Zhilovets пишет:
> Не сказал бы, что это такая уж проблема. Реально с
> несовместимостями между разными версиями Windows я
> сталкивался раза три-четыре за несколько лет.

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

> А зачем мне вообще сдался этот С и его кривые макросы?
> Какое отношение он имеет к ОС и ее функциям?

Наверное, то же самое, которое С++ и его кривые объекты имеют к Винде и её COM ? ;-)

> И что мне делать, когда завтра выкинут функцию __xfstat  и
> введут функцию __izvrat ? Срочно перекомпилировать все
> программы, включая пользовательские?

Варианты:
1) юзать старую версию либы или конкретного API (RTFM на предмет soname и symbol versioning);
2) держать отдельную либу-враппер, с вариантами под каждый значимый вариант API нижележащей либы;
3) юзать dlopen()/dlvsym();
4) юзать LD_PRELOAD чтобы подсунуть программе свои реализации исчезнувших API;
5) или можно именно перекомпилировать.

Как говорится, кто хочет делать - ищет возможности; кто не хочет - ищет причины. ;-)

> Ни Перл, ни Питон, кстати, не дают возможности напрямую
> вызывать функции ОС, а сами компиляторы написаны на С. Так
> что это сложно назвать решением.

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

> Реентерабельных и нереентерабельных функций - которые можно
> вызывать в обработчике сигнала и которые нельзя.

Да, для Линукса есть список. И есть простые и вполне очевидные правила, обуславливающие что в него попадает:
http://www.gnu.org/software/libtool/manual/libc/Nonreentrancy.html
В то время как улетевшая в никуда по подобным причинам виндовая программа просто будет воспринята всеми свидетелями и участниками как "еще один глюк Винды", перезапущена и забыта - под Линуксом это знаковое событие хотя бы можно постараться предотвратить. ;-)

А для Форта и обработчика исключений в нём, всё это параллельно в любом случае: когда у тебя упала в исключение системная функция, то её реентерабельность это наименьшая из твоих проблем. :-)


-= With best regards, Dmitry Groshev =-


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Добрый день, Yuriy Zhilovets!

Ваше сообщение от 23.02.2008 18:12:
> Ну это слишком категорично. Ядро там очень изощренное, а вот API
> никуда не годится: и выглядит старорежимно, и многих полезных вещей
> нет, и заточен под один и не самый лучший язык. Никогда не понимал,
> зачем для написания свободной ОС надо было брать за образец именно Юникс?
У Линуса не было задачи сделать свободную ОС. Я так понимаю, были некие
эксперименты с многозадачностью, которые не хотелось бросать (ну любит
человек программировать, как и мы). И чтобы сделать из этого нечто
полезное, а не оставлять на том уровне, на котором остаются 99.9%
самодельных ОС (любительские эксперименты), нужно было посадить сверху
какой-нибудь софт. Причем готовый, т.к. более ядра самому не осилить. А
не было ничего такого кроме GNU. И университетской привычке к юниксу.
Так всё в одно и сложилось. Сначала (93-95гг) это было отличной заменой
DOSу (наш фидошный админ поставил у себя Linux первым в городе - как раз
году в 93м). Потом оказалось, что этим инструментом можно как-то пинать
старых юниксовых динозавров, точнее их PCшные продукты - такие как
InteractiveUnix и SCO Unix (в немецкой фирме, в которой я работал в
94-96м iu-юниксовые проекты свернули в 95м, и там же я впервые увидел
первые "брендовые" линуксы). Потом оказалось, что можно пошантажировать
ими MS. По-моему, сейчас задача свержения винды с десктопов является
основной целью (судя по активности этих проектов). Деструктивная по сути
задача - разъединение объединенного Биллом мира :) Когда (и если) Linux
и Маки отвоюют хотя бы по 10%, начнется закручивание лицензионных гаек в
MS-стиле. Хотя мало кто из пользователей это заметит - ось покупают с
компьютером, включенной её цены никто не знает (как с осями в
мобильниках), а там лишь бы браузер и игры работали :)
>> (если кто помнит историю появления REQUIRE в SPF :).
> А я ее и не знал. Идея была сделать нечто в стиле Ребола?
А я не знал, что такое есть в Реболе :) Идея была такая просто потому,
что на тот момент на SPF уже был написан веб-сервер :) Может были
какие-то более прямые мотивы, я не помню.

P.S. Отчитываюсь: игрековый вариант posix-spf после минимальных правок
(в бэкслэшах, регистрах букв и удаления NOWADAYS) успешно
скомпилировался yz-вариантом posix-spf под FC8 (т.е. из тех же сырцов,
из которых работоспособная виндовая версия компилится jpf или spf),
успешно слинковался, но работать полученный бинарник на линуксе
отказался. Хотел закоммитить изменения, но досовые строки в подкаталогах
CVS возмутили линуксовый CVS, и еще неизвестно что бы он с делал с
репозиторием, отправив туда "досовые" сырцы. В общем, надо работать под
чем-то одним, а не копировать туда-сюда :) SPF мы можем приучить к любым
строкам, чего не скажешь об инструментах под линуксом.

Кстати, промежуточный итог: мы имеем уже ТРИ варианта SPF, с wine
четыре, работающих под линуксом в той или иной степени стабильно и
совместимо. Достаточно для того чтобы вырастить из этого (нарастить на
этом) все что угодно. Но вопрос "а что именно нам угодно?" остается
открытым :)

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Some javascript/style in this post has been disabled (why?)

Добрый день, Dmitry Groshev!

Ваше сообщение от 23.02.2008 20:58:

А зачем мне вообще сдался этот С и его кривые макросы?
Какое отношение он имеет к ОС и ее функциям?
    

Наверное, то же самое, которое С++ и его кривые объекты имеют к Винде и её COM ? ;-)
  

Да, да! Это следующие уровни, выравнивающие недоработки на предыдущих.
И добавляющие новые проблемы.
Винда ведь тоже разновидность юникса, у них есть общие болезни,
включая зависимость от Си и неуважение к другим языкам :)


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Добрый день, Dmitry Groshev!

Ваше сообщение от 23.02.2008 20:58:
> Да, для Линукса есть список. И есть простые и вполне очевидные правила, обуславливающие что в него попадает:
> http://www.gnu.org/software/libtool/manual/libc/Nonreentrancy.html
>  
Очень уместно процитировать твою цитату

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

> В то время как улетевшая в никуда по подобным причинам виндовая программа просто будет воспринята всеми свидетелями и участниками как "еще один глюк Винды", перезапущена и забыта - под Линуксом это знаковое событие хотя бы можно постараться предотвратить. ;-)
>  
А я вот зависания Линукса так воспринимаю - как еще один глюк Линукса
(только за вчера два было). И вовсе мне не хочется при этом искать, что
именно привело к неработоспособности или внезапным жутким тормозам -
глюки ядра, сети, драйверов видео, гнома или firefox'а - и составлять
багрепорты. Проще с облегчением вернуться на винду, которая практически
не глючит со времен NT4 :)

> А для Форта и обработчика исключений в нём, всё это параллельно в любом случае: когда у тебя упала в исключение системная функция, то её реентерабельность > это наименьшая из твоих проблем.

C этим тоже беда: если у меня падает виндовая функция, то я практически
на 100% знаю, что дело НЕ в её реентерабельности, потому что ядерные
функции в винде 100% реентерабельны, т.е. можно просто не задумываться о
целом слое самых трудноловимых проблем. А в юниксах, в которых
многопоточность прикручена ad hoc - через 20 лет после разработки
основных концепций ядра и львиной доли системного софта - об этой
проблеме придется помнить. Если она вылазит боком даже в колбэках в
однопоточной программе, то что будет в многопоточной? Юниксоиду проще
ответить, что многопоточность - это тоже моя проблема, а не юникса, и
что "нормальные люди" её не используют (тут опять см. цитату выше :) На
самом деле "нормальные люди" просто не умеют, т.к. в частности
"нормальные" инструменты не позволяют.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Dmitry Yakimov-2]

Dmitry Groshev wrote:

> Приветствую!
>
> Yuriy Zhilovets пишет:
>  
>> Не сказал бы, что это такая уж проблема. Реально с
>> несовместимостями между разными версиями Windows я
>> сталкивался раза три-четыре за несколько лет.
>>    
>
> Я не настолько удачлив - одних только случаев несовместимостей помню с десяток. А к ним следует прибавить недокументированные багофичи, ошибки в доках и откровенное враньё в них же - после всего этого, сырцы мне куда симпатичнее чем мануалы.
>  

В ядре каждый день добавляется по 4000 строчек кода и 2000 модифицируется.
Все движется очень быстро, про документацию не всегда вспоминают.

Дмитрий.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Dmitry Yakimov-2]

Привет,

Andrey Cherezov wrote:

> Добрый день, Yuriy Zhilovets!
>
> Ваше сообщение от 23.02.2008 18:12:
>  
>> Ну это слишком категорично. Ядро там очень изощренное, а вот API
>> никуда не годится: и выглядит старорежимно, и многих полезных вещей
>> нет, и заточен под один и не самый лучший язык. Никогда не понимал,
>> зачем для написания свободной ОС надо было брать за образец именно Юникс?
>>    
> У Линуса не было задачи сделать свободную ОС. Я так понимаю, были некие
> эксперименты с многозадачностью, которые не хотелось бросать (ну любит
> человек программировать, как и мы). И чтобы сделать из этого нечто
> полезное, а не оставлять на том уровне, на котором остаются 99.9%
> самодельных ОС (любительские эксперименты), нужно было посадить сверху
> какой-нибудь софт. Причем готовый, т.к. более ядра самому не осилить. А
> не было ничего такого кроме GNU. И университетской привычке к юниксу.
> Так всё в одно и сложилось. Сначала (93-95гг) это было отличной заменой
> DOSу (наш фидошный админ поставил у себя Linux первым в городе - как раз
> году в 93м). Потом оказалось, что этим инструментом можно как-то пинать
> старых юниксовых динозавров, точнее их PCшные продукты - такие как
> InteractiveUnix и SCO Unix (в немецкой фирме, в которой я работал в
> 94-96м iu-юниксовые проекты свернули в 95м, и там же я впервые увидел
> первые "брендовые" линуксы). Потом оказалось, что можно пошантажировать
> ими MS. По-моему, сейчас задача свержения винды с десктопов является
> основной целью (судя по активности этих проектов). Деструктивная по сути
> задача - разъединение объединенного Биллом мира :)

Я бы это назвал естественным отбором :)
> Когда (и если) Linux
> и Маки отвоюют хотя бы по 10%, начнется закручивание лицензионных гаек в
> MS-стиле.

Не уверен что много можно накрутить когда треть софта под gpl3 лицензией.

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

Дмитрий.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Dmitry Yakimov-2]

Andrey Cherezov wrote:

> Добрый день, Dmitry Groshev!
>
> Ваше сообщение от 23.02.2008 20:58:
>>> А зачем мне вообще сдался этот С и его кривые макросы?
>>> Какое отношение он имеет к ОС и ее функциям?
>>>    
>> Наверное, то же самое, которое С++ и его кривые объекты имеют к Винде и её COM ? ;-)
>>  
> Да, да! Это следующие уровни, выравнивающие недоработки на предыдущих.
> И добавляющие новые проблемы.
> Винда ведь тоже разновидность юникса

Разновидность vmx если быть точным :)

Дмитрий.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[ygrek-3]

Привет,

> >5) дальше идут не неудобства, а непонятки
> >[root@rainbow ~]# ./spf4
> >[титры]
> >REQUIRE [UNDEFINED] lib/include/tools.f
> >----------------------------------------------------------------
> >[Segmentation fault]  Code:1  Address:080507A6  Word:Ошибка
> >сегментирования
> >
> >  
> >
> Похоже на оптимизатор.

Больше похоже на мой косяк :)
VOC-LIST неправильный был с учётом >VIRT
Теперь VOCABULARY работает ок, но tools.f всё равно сбоит

ЗЫ под root'ом - ай-яй-яй

--
 ~ygrek


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Dmitry Groshev-2]

Приветствую!

Andrey Cherezov пишет:
>Конечно проще вместо поиска причины и ликвидации нереентерабельности (исправить которую нельзя, т.к. автор умер в прошлом веке) пишут мануал по "поиску возможностей" вечной жизни с этой проблемой.

IMHO всё же стоило сперва сходить по ссылке. ;-)
Лично я не вижу, каким вообще образом можно "устранить нереентерабельность", связанную с не-атомарностью всех сколь-нибудь сложных операций. Если гонки _между_ потоками ещё в принципе можно исключить совсем, пришпилив мутекс к каждой переменной (и помахав производительности платочком вслед) - то насчёт гонок _внутри_ потока это уже к господу богу, жаловаться на неправильно сотворённый мир. ;-)
Можно, конечно, поступить как в Виндах - если асинхронных сигналов не будет вообще, то не будет и проблем с ними связанных - а можно исходить из принципа, что некоторые из программистов всё же наделены мозгами и чётко обозначенные грабли способны обойти, а всех прочих никто не заставляет туда соваться.

> А я вот зависания Линукса так воспринимаю - как еще один глюк Линукса
> (только за вчера два было).

Какой дистрибутив? Хочется знать, от чего держаться подальше. :-)
Лично у меня MOPS Linux 5.1 надёжен как скала.

> Проще с облегчением вернуться на винду, которая практически
> не глючит со времен NT4 :)

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

> C этим тоже беда: если у меня падает виндовая функция, то я практически
> на 100% знаю, что дело НЕ в её реентерабельности, потому что ядерные
> функции в винде 100% реентерабельны,

Плохо, когда слышали звон, но не поинтересовались где он...
_Ядро_ в Линуксе, разумеется, реентерабельно. Большинство библиотек также реентерабельно - из _разных_ потоков. А реентерабельность всех функций из _того_же_ потока - бред воспалённого мозга: если некая функция блокирует некий объект и с ним работает, и в это время её прерывают и вызывают снова - то разблокирования объекта она будет ждать вечно.
А способ решения проблемы известен всем, кому он нужен: асинхронный обработчик должен сообщить о сигнале в _другой_ поток, который уже и займётся обработкой, и спокойно возвратить управление.

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

Всё в порядке будет - и в той, и в другой. Если, конечно, приложить к делу прямые руки.

> Юниксоиду проще
> ответить, что многопоточность - это тоже моя проблема, а не юникса, и
> что "нормальные люди" её не используют (тут опять см. цитату выше :) На
> самом деле "нормальные люди" просто не умеют, т.к. в частности
> "нормальные" инструменты не позволяют.

Да, я знаю - "нормальная" винда не позволяет fork(), поэтому виндузятники парятся с потоками; но зачем же выдавать нужду за добродетель? :-)
Ядру Линукса нет разницы - процесс или поток: переключение одинаково дешёвое. Поэтому я имею выбор - хочу ли я делать _всю_ память общей для всех потоков, или в данной конкретной задаче удобнее будет без этого. Можно, конечно, спорить, что иметь выбор - это плохо и неправильно... ;-)


-= With best regards, Dmitry Groshev =-


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[ygrek-3]

Привет,

> Больше похоже на мой косяк :)
> VOC-LIST неправильный был с учётом >VIRT
> Теперь VOCABULARY работает ок, но tools.f всё равно сбоит

Теперь tools.f подключается и работает :)
Добавил >VIRT в 'DROP который попадает в noopt.f
Удивляюсь почему без этого работало в оригинальной версии.
Хотя там не было noopt.f, а кроме этого он больше нигде не используется
вроде..

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

--
 ~ygrek


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Добрый день, ygrek!

Ваше сообщение от 24.02.2008 11:30:
> ЗЫ под root'ом - ай-яй-яй
>  
Ха-ха, так и думал, что кто-нибудь укажет :-) Если найдешь мои более
ранние дампы
про линуксовые SPF, то там везде ac@rainbow.
Только что заменял FC7 на FC8 (потому что FC7 почти умер после замены
железа),
причем обновление FC7->FC8 не удалось (после длительной якобы установки
пишет
ошибку "пакет уже установлен" и снова загружается FC7 :), пришлось всё с
нуля
переставить, т.е. система полурабочая - постоянно что-то доставляется -
а это все
же удобнее из под рута - sudo действует мне на нервы на порядок больше, чем
вистовый UAC.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Some javascript/style in this post has been disabled (why?)

Добрый день, Dmitry Yakimov!

Ваше сообщение от 24.02.2008 10:50:

Да, да! Это следующие уровни, выравнивающие недоработки на предыдущих.
И добавляющие новые проблемы.
Винда ведь тоже разновидность юникса
    

Разновидность vmx если быть точным :)
  

Нет, это столь же не точно ;)
Там идеи взяты отовсюду - и из vms (переманили разработчиков vax/vms из DEC), и из собственного
варианта Unix'а (MS Xenix, ставшего потом SCO Unix), и из доса, и из OS/2 (winNT3.1=os/2v3).
Вообще при разработке NT стояла задача в том числе и совместимости с Posix (стандарт
которого был как раз в это время и выпущен, т.е. NT стала одной из первых реализаций).
Да было бы глупо, если бы на тот момент (конец 80х) NT не впитала лучшие идеи всех
зрелых на тот момент осей и каких-то новых пока еще витавших в воздухе идей.
Потому и получилось лучше, чем Unix. Плохо то, что при этом стала и значительно сложнее,
отсюда и все беды.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Добрый день, Dmitry Groshev!

Ваше сообщение от 24.02.2008 15:31:
> Лично я не вижу, каким вообще образом можно "устранить нереентерабельность", связанную с не-атомарностью всех сколь-нибудь сложных операций. Если гонки _между_ потоками ещё в принципе можно исключить совсем, пришпилив мутекс к каждой переменной (и помахав производительности платочком вслед) - то насчёт гонок _внутри_ потока это уже к господу богу, жаловаться на неправильно сотворённый мир. ;-)
>  
Мутексы нужны только для неразделяемых ресурсов. А реентерабельность
реализуется легко - исключением глобальных переменных и прочих
глобальных структур. Делов то.
> Можно, конечно, поступить как в Виндах - если асинхронных сигналов не будет вообще, то не будет и проблем с ними связанных - а можно исходить из принципа, что некоторые из программистов всё же наделены мозгами и чётко обозначенные грабли способны обойти, а всех прочих никто не заставляет туда соваться.
>  
Асинхронные сигналы в Виндах есть.
> Какой дистрибутив? Хочется знать, от чего держаться подальше. :-)
> Лично у меня MOPS Linux 5.1 надёжен как скала.
>  
Я же написал вчера - FC8. Тоже бывало в FC с 5 по 7. Все мне говорят,
что FC для тестов и сделана, и что мол ждать там стабильности не стоит,
поэтому не поленился в прошлом году еще на отдельной машине поставить
Debian (конкретно Ubuntu). Тоже глючит временами. И это при том что я
работаю с линуксом редко - в основном по сетевым делам (мы - провайдеры,
у нас юникс в сотнях железок по всей области) и для испытания каких-то
программ в их родной среде (вместо cygwin и портов).
> Могу только пожелать счастливого пути - на Линукс никого силком не тащат. Интересоваться, где берут такую безглючную винду, не буду - для меня она уже пройденный этап.
>  
Да, тоже самое я говорю про людей, попробовавших Форт, и возвращающимся
на свои прежние инструменты. Каждому своё. А я просто использую всё -
какой-то задаче лучше винда, какой-то unix; какой-то программе лучше
Forth, какой-то JavaScript, какой-то XSLT, и т.д. Как там говорится, "я
говорю по-английски с торговцами, по-итальянски с женщинами,
по-французски с мужчинами, по-испански с богом, а по-немецки с моей
лошадью"? Не пройденные этапы, а освоенные этапы.
> Плохо, когда слышали звон, но не поинтересовались где он...
>  
Вот именно :)
> _Ядро_ в Линуксе, разумеется, реентерабельно. Большинство библиотек также реентерабельно - из _разных_ потоков. А реентерабельность всех функций из _того_же_ потока - бред воспалённого мозга: если некая функция блокирует некий объект и с ним работает, и в это время её прерывают и вызывают снова - то разблокирования объекта она будет ждать вечно.
>  
Блокировки не имеют прямого отношения к реентерабельности. Блокировками
(доступа к глобальным данным) _пытаются_ решать задачу
реентерабельности. А можно просто минимизировать (а то и вовсе
исключить) работу с глобальными данными, тогда никаких блокировок не
понадобится.
"Реентерабельность функций из того же потока" - "бред воспаленного
мозга"? А как насчет рекурсии? ;)
Если речь об обработке прерываний, о колбэках из оси в пользовательский
код (а оттуда обратно в ось), то это нельзя однозначно считать одним
потоком (управления), т.к. там все же часто создается отдельный стек, а
это уже почти отдельный поток. В SPF по умолчанию колбэки обрабатываются
как потоки, поэтому автоматически реентерабельны.
> Всё в порядке будет - и в той, и в другой. Если, конечно, приложить к делу прямые руки.
>  
Это само собой. Последний аргумент юниксоида (равно как и фортера :).
> Да, я знаю - "нормальная" винда не позволяет fork(),
Ха, был уверен, что так будет сказано :-) Очень запросто позволяет винда
fork()! Даже был такой вирус, который это использует. Я в 2002м
прикручивал к Eserv'у антивирусные API, и при испытаниях случайно
запустил живой вирус - у меня от его заражения все зараженные форты
начали форковать (вместо нормального запуска отдельного процесса) - то
есть запускаешь CreateProcess(сам_себя), а получаешь не "чистый" новый
процесс, а копию работающей сессии, включая всё что там скомпилировал в
словарь. Потому что вирус пометил все секции exe как shared. Для полной
эмуляции fork'а достаточно было сделать jmp. Я описывал это где-то в
сетях тогда (сначала подумал, что глюк какой-то удивительный :).
А о том что для винды уже больше 15 лет (столько же, сколько в Linux'е,
или даже больше, учитывая что разработка NT стартовала на пару лет
раньше) существует и обычных posix'овый fork() (в psxdll.dll) я уже и не
говорю - его даже cygwin не использует, т.к. собственные виндовые
функции лучше.
>  поэтому виндузятники парятся с потоками; но зачем же выдавать нужду за добродетель? :-)
>  
Ну-ну. А зачем тогда в линуксе прикрутили в конце-концов потоки - только
чтобы винду эмулировать? ;) Или просто чтобы, наконец, стать полностью
POSIX-совместимыми? Ну а зачем в posix'е тогда потоки сделали?
> Ядру Линукса нет разницы - процесс или поток: переключение одинаково дешёвое.
Одинаковое - потому, что многопоточность там эмулируют на базе
многозадачности. А если б была родная реализация многопоточности -
потоки были бы дешевле по любому.
> Поэтому я имею выбор - хочу ли я делать _всю_ память общей для всех потоков, или в данной конкретной задаче удобнее будет без этого. Можно, конечно, спорить, что иметь выбор - это плохо и неправильно... ;-)
>  
Повторюсь: все, что есть в юниксе, есть и в винде, но не всегда
справедливо обратное. Да, в винде создание процесса дороже, чем в юниксе
- по той же самой причине (толще, сложнее).

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Andrey Cherezov]

Добрый день, ygrek!

Ваше сообщение от 24.02.2008 17:51:
> WordByAddr поломанный, поэтому идёт вложенный segfault при дампе стека
> возвратов. Пока отключил его в дампе, чтобы хотя бы по адресам можно
> было ориентироваться.
>  
Он не поломанный - в винде же работает (SEH на то и 'structured'). Это в
Linux'е с
вложенными segfault может быть проблема (пряморукий Dmitry Groshev поможет
авось).

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev

[Dmitry Groshev-2]

Приветствую!

Andrey Cherezov пишет:
> А реентерабельность
> реализуется легко - исключением глобальных переменных и
> прочих глобальных структур. Делов то.

Да, давайте исключим регистры процессора. Делов-то. ;-)
Ссылочку, я вижу, Вы так и не глянули - а зря.

> Асинхронные сигналы в Виндах есть.

Какие именно?

> поэтому не поленился в прошлом году еще на отдельной машине
> поставить Debian (конкретно Ubuntu). Тоже глючит временами.

Ставил и такое - снёс в первый же день. Не все дистры одинаково полезны. ;-)

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

Если лишние знания о Линуксе уважаемому сэру ни к чему, то мне пустая говорильня не нужна и подавно - я, кажется, уже упоминал что в этом забеге моей лошади нет. Если же сэр всё-таки пожелает узнать о чём же собственно идёт речь в нашем странном диалоге, эту информацию можно найти по уже упомянутой ссылке:
http://www.gnu.org/software/libtool/manual/libc/Nonreentrancy.html

> "Реентерабельность функций из того же потока" - "бред
> воспаленного мозга"? А как насчет рекурсии? ;)

А никак. Не надо путать божий дар с яичницей.
Рекурсивная функция вызывает саму себя из чётко определённых точек - тем и жива. Если некто третий начнёт втыкать вызовы куда попало - то можете, наверное, представить себе результат.

> Если речь об обработке прерываний, о колбэках из оси в
> пользовательский код (а оттуда обратно в ось), то это

Вот именно о них и речь. То, что в Линуксе это называется "сигнал", сути дела не меняет.

> нельзя однозначно считать одним
> потоком (управления), т.к. там все же часто создается
> отдельный стек, а это уже почти отдельный поток. В SPF по

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

Отдельный стек для сигналов, кстати, в Линуксе надо попросить через sigaltstack(). И просить его придётся - иначе обработка переполнения стека закончится не начавшись.

> раньше) существует и обычных posix'овый fork() (в
> psxdll.dll) я уже и не говорю - его даже cygwin не
> использует, т.к. собственные виндовые функции лучше.

Нет, там другая причина - Win32 подсистема с ним дружить не приучена.
Я вообще-то в курсе, какими способами и через какое место в виндах эмулируется fork() - случилось изучать вопрос. В курсе и что народ от этого плюётся - очень уж сильно медленнее это в виндах работает.

> Ну-ну. А зачем тогда в линуксе прикрутили в конце-концов
> потоки - только чтобы винду эмулировать? ;) Или просто
> чтобы, наконец, стать полностью POSIX-совместимыми? Ну а

Вообще-то POSIX отнюдь не требует реализовывать потоки на уровне ядра - наоборот, Линукс имел немало проблем с POSIX-совместимостью именно из-за такой их реализации, и избавился от них только в ядре 2.6.
А вот для Wine именно такая реализация потоков, действительно, весьма удобна. :-)

> зачем в posix'е тогда потоки сделали?

Наверное, для тех случаев, когда от них бывает польза.

Просто когда из инструментов один молоток - то повсюду мерещатся гвозди; а когда есть ещё и отвёртка, то среди гвоздей начинаешь различать шурупы. :-)

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

Ну, в этом вопросе я как-то более склонен верить Линусу Торвальдсу. Не нам учить его писать операционки. ;-)

> Повторюсь: все, что есть в юниксе, есть и в винде, но не
> всегда справедливо обратное.

Искренне рад за вашу винду; сожалею что мне такой не досталось. ;-)


-= With best regards, Dmitry Groshev =-


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Spf-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/spf-dev