Forth и другие саморасширяющиеся системы программирования Locations of visitors to this page
Текущее время: Чт мар 28, 2024 15:10

...
Google Search
Forth-FAQ Spy Grafic

Часовой пояс: UTC + 3 часа [ Летнее время ]




Начать новую тему Ответить на тему  [ Сообщений: 18 ]  На страницу 1, 2  След.
Автор Сообщение
 Заголовок сообщения: Чистим за собой
СообщениеДобавлено: Вс окт 05, 2008 05:54 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Автор: Anton Ertl
Статья опубликована на ЕвроФорт2008
Перевел: mOleg

Чистим за собой.

Аннотация.

Выполнение действий очистки, таких как восстановление переменных или закрытие файлов невозможно было гарантировать в Форте до 94 стандарта, который дал нам CATCH THROW механизм. Но даже с CATCH возможны ситуации, когда восстановление будет пропущено из за пользовательских прерываний, если вы будете неудачливы. Мы предлагаем конструкцию, которая гарантирует, что код
восстановления(очистки) всегда будет выполнен. Мы так же обсудим более легкие предложения реализации для кода чистки восстановления), нежели использование полного фрейма исключения.


Введение

Частая проблема, встречаемая в программировании - восстановление некоторого состояния, освобождения ресурса, или выполнения другого обязательного завершающего действия. Типичные примеры:
- восстановление переменной BASE после временного изменения;
- закрытие файла.

В Форт-94 мы можем использовать CATCH для гарантии что такая очистка произойдет в большинсте (но не во всех) случаях. В этой статье мы исследуем пути для улучшения состояния дел следующим образом:
- предоставим более надежный механизм, который работает даже в случае асинхронного исключения (в том числе, пользовательского прерывания);
- избегание полного фрейма исключения, где это возможно.


Используемый пример.

Как используемый пример, мы будем использовать слово hex. , которое печатает число в шестнадцатиричной системе исчисления без изменения состояния переменной BASE . И это слово будет использоваться в следующем контексте:

: foo
... hex. ...
... . ... ;

DECIMAL foo
HEX foo

Заметте, что в дополнение к печатанию числа в шестнадцатиричной системе , foo так же печатает числов в текущей системе исчисления.

Классическое форт-решение.

Подход из "Thinking Forth".

В старые дни, когда форт не имел механизма CATCH THROW , было бы написано подобным образом:
: hex. ( u --> )
BASE @ >R
HEX U.
R> BASE ! ;

Но даже тогда были возможны не локальные выходы через ABORT и QUIT , так же как и через пользовательские прерывания. Если любые из этих нелокальных выходов или прерываний произойдут, BASE не будет восстановлена.
Таким образом, раньше восстановление не могло быть произведено гарантированно. В результате были изобретены различные пути для обхождения проблемы, как, например, в "Thinking Forth", параграф 7, секция сохранение и восстановление состояний[1]. В особенности, эта секция ссылается на Чака Мура следующим образом:
"Вы действительно завязаны в узел. Вы создаете проблему для себя. Если я хочу получить шестнадцатиричный дамп, я говорю: HEX DUMP . Если я хочу получить десятичный дамп, я говорю: DECIMAL DUMP . Я не позволяю слову DUMP изменять мое окружение.
Существует философский выбор между восстановлением состоянии по окончании действия, и предопределением состояния в начале действия. Длительное время я думал, что лучше восстанавливать состояние по окончании действия. И я пытался так поступать везде, но очень сложно так поступать всегда. Теперь я стараюсь предопределять состояние перед началом действия.
Чем заботиться о переменных, лучше устанавливать их. Если кто-то другой изменяет переменные, он не должен заботиться о их восстановлении. Всегда больше выходов, чем входов."

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

Использование CATCH.
К счастью, с появлением механизма CATCH в 94 стандарте ситуация изменилась: существует всего один выход из CATCH , и мы можем использовать это свойство для освобождения ресурсов более надежно:
: hex.-helper ( u -- ) hex u . ;
: hex. ( u --> ) BASE @ >R ['] hex.-helper CATCH R> base ! THROW
Это позволяет быть уверенным, что переменная будет восстановлена даже в случае возникновения исключения (любого типа) во время исполнения слова hex.-helper .
Тем не менее существует одна прореха в нашей броне: Если исключение ( в том числе пользовательское прерывание) произойдет во время восстановления BASE, восстановительный код не будет завершон, и переменная сохранит неверное состояние.

Улучшенные решения.

Try...restore...endtry

В текущей верси GFORTH предлагается конструкция try code1 restore code2 endtry . Если любое исключение возникнет где-нибудь между try и endtry (в том числе в code2 ), глубина стека данных сбросится на состояние, предшествующее выполнению try , значение исключения будет положено на стек данных, и исполнение будет передано коду начинающегося со слова restore .
С этой конструкцией имеем не только один выход, так же гарантируется, что code2 будет исполнено с начала до конца.
Эта конструкция может использоваться для решения нашей проблемы следующим образом:
Код:
  : hex. ( u -- )
         BASE @ { oldbase }
         try
           hex .
           0 \ значение для THROW
         restore
           oldbase BASE !
         endtry
         THROW ;


Старое значение переменной BASE сохраняется в локальной переменной, потому что мы не можем использовать стек возвратов для этой цели (try кладет фрейм исключения на стек возвратов). Однако, в замен использования локальной переменной, мы можем использовать стек данных следующим образом:
Код:
: hex. ( u -- )
       base @
       try
        over hex .
        0 \ значение для THROW
       restore
        over base !
       endtry
       THROW
       2DROP ;

Пример того, как можно использовать OVER для хранения значений на стеке данных нетронутым так, что мы можем использовать их в восстанавливающем коде. Только мы должны эти значение удалить после выполнения кода endtry.
Данная конструкция требует некоторой осторожности при использвании:
- как показано выше, необходимо заботиться о том, чтобы значение с вершины стека данных не снималось; оно не должно сниматьс оттуда даже во время восстановление состояния.
- восстанавливающий код не должнен вызывать исключений как минимум во время своего исполнения. Иначе система попадет в бесконечный цикл состоящий из начала восстановительного процесса и вызова нового исключения. И пользователь не сможет прервать данный процесс не используя некорректные методы ( такие как сброс, или посылка сигнала SIGTERM в юниксе).
- Восстанавливающий код должен иметь возможность многократного исполнения, то есть не должен изменять состояние стека данных во время своего исполнения, и повторное выполнение кода должно приводить к такому же результату, как и однократное.

В любом случае, форт-программисты относятся ответсвтенно к своим программам и эти предупреждения не должны быть проблемой. Предъявляемые требования не всегда возможно реализовать (либо очень сложно), когда очистка\восстановление относится к закрытию файлов или освобождения блоков памяти. В таких случаях обычно предпочтительно иметь небольшой шанс невыполнения очистки, чем
многократного выполнения. Некоторые могут пытаться разрешить проблему с помощью размещения кода, который не должен быть повторно выполнен между словами endtry и THROW .
В случаях, когда переменные изменяются и восстанавливаются такое требование выполнить легко. Пример последнего:
Код:
... open-file throw { f }
try
... f read-file throw ...
0 restore
endtry
f close-file throw
throw

Слова специального назначения.

GForth так же имеет слова специального назначение для редких, либо опасных назначений:
base-execute ( i*x xt u -- j*x ) - выполняет xt пока BASE установлена в u.
infile-execute ( i*x xt file-id -- j*x ) - выполняет xt пока KEY итп читает входной поток из file-id
outfile-execute ( i*x xt file-id -- j*x ) - выполняет xt пока исходящий поток, TYPE и подобные перенаправлены в file-id.

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

Эффективность.

Фрейм исключения занимает пять ячеек на стеке возвратов в Gforth (а так же, вероятно, в других системах), а так же отнимает некоторое время на его оформление. Для вопросов восстановления полный фрейм исключения избыточен. Мы не нуждаемся в восстановлении всех стеков в данном случае: если мы вошли в востанавливающую часть нормальным образом, стеки не /восстанавливаются вообще; если мы попали в восстанавливающую часть с помощью THROW, мы передаем исключение дальше, и нам не надо восстанавливать стеки. То есть нам нужна только информация, достаточная для восстановления данных.
Таким образом мы можем реализовать легковесный механизм для восстановления. Двух ячеек для фрейма будет достаточно. Восстановительные фреймы могут храниться на стеке возвратов, и быть связанными в однонаправленный список. THROW будет исполнять все восстанавливающие фреймы, находящиеся перед следующим фреймом исключения на стеке возвратов, затем
обрабатывать фрейм исключения обычным образом.
Обратная сторона такого подхода заключается в том, что восстанавливающий код и данные могут быть более осведомлены о механизме восстановления, потому что восстанавливаемые данные не могут быть прямо переданы через стеки, но могут быть доступны через фрейм восстановления. То есть восстанавливающий код для BASE может выглядеть следующим образом:
Код:
: restore-base ( addr -- )
                dup @ base !
                next-restoration ;

Тут, addr - это адрес пользовательской части фрейма восстановления. Next-restoration ( addr -- ) удаляет текущий фрейм восстановления из цепочки. Любая последовательность, которую нельзя исполнять повторно должна происходить после next-restoration .
Реализация base-execute с подобным механизмом может выглядеть так:
Код:
: base-execute ( i*x xt u -- j*x )
               base @ >r
               ['] restore-base >restore
               base ! execute
               restore>
               r> drop ;

Где, >restore будет добавлять восстановительный фрейм на стек возвратов и связвать в восстановительную цепочку. Restore> будет исполнять восстанавливающий xt и удалять его с вершины стека возвратов. Старая BASE будет полностью удалена.
Предлагаемый механизм еще не реализован. Пока его будет сравнительно легко создать, еще не ясно, стоит ли сопровождать документацией и поддержкой для предоставления пользователям. Имеется несколько моментов для обсуждения:
- мой опыт показывает, что почти все пользователи пользуются CATCH механизмом для восстановления\очистки. Таким образом большинство фреймов исключения может быть заменено более легкими восстанавливающими фреймами.
- фреймы исключений и их поддержка не показали критического понижения быстродействия, но я не производил никаких измерений.

Родственная работа.
Я не осведомлен о других расширенных решениях в форте. Ведь это часто встречающаяся программистская проблема, поэтому в других языках разработана широкий выбор решений.

Динамический контекст.

Часть проблем, рассмотренных в данной статье, например, наш вариант работы с BASE может быть рассмотрен, как подгонка окружения исполнения. Хансон и Проебстринг [2] аргументирует, что переменные динамического контекста имеют правильные свойства для этого использования и программистам языков без поддержки динамического окружения приходится симулировать динамическое окружение. Они указывают на подобность между исключениями (система с динамическим окружением) и динамически изменяемых переменных (которые объясняют почему обычно используют ловлю исключений в реализациях).
Значительное число языков программирования и систем предоставляют переменные динамического контекста. Но, вероятно, более широко используемый пример - переменные окружения в UNIX и WINDOWS процессах.
Другой известный язык с переменными динамического контекста - Postscript, в котором программисты выполняют динамический контекст с помощью (с использованием терминологии Форта) создавая словари динамически, и добавляя и в стек контекста, потому что поиск имет в Постскрипте производится во время исполнения кода, это и создает динамический контекст. В любом случае слова
динамического управления (exit, stop) не воздействуют на глубину стека передачи управления (возвратов), и обсуждаемые свойтсва не могут быть скомбинированы безопастным образом.

Очистка.

Лисп имеет специальный механизм unwind - protect обеспечивающий уверенность в том, что очистка будет выполнена в любом случае, даже при критическом выходе из protected. Однако, в отличие от try...restore...endtry механизм не защищает от исключения из cleanup части. Ява имеет подобный механизм в форме try...finally конструкции, и в С++ в виде try...catch . С++ так же предоставляет механизм деструкторов, которые могут автоматически освобождать ресурсы и выполнять другую освобождающую работу когда контекст переменной удален. Страуструп [3] дает хороший обзор подобного рода безопастных исключений, поэтому теперь многие решения на C++ их используют. Аналогично финализаторы в Яве выполняют освобождающие действия во время сборки мусора. Так как финализатор может быть исполнен значительно позже деструктора, часто рекомендуют предпочитать другие подходы вместо финализаторов. Много других языков имеет подобные средства.

Итог.
Введение механизма CATCH в 94 стандарте языка Форт предоставляет хороши базис для написания кода, который чистит за собой, и не требует кода чистящего мусор впоследствии. Тем не менее, существование пользовательских прерываний и асинхронных исключений делает существующие механизмы недостаточными. В статье предлагается try ... restore ... endtry конструкция для решения перечисленных проблем полность, но не во всех случаях. Были так же рассмотрены более легкие реализации механизма.

Ссылки.
[1] Leo Brodie. Thinking Forth. Fig Leaf
Press (Forth Interest Group), 100 Dolores
St, Suite 183, Carmel, CA 93923, USA,
1984.
[2] David. R. Hanson and Todd A. Proebsting.
Dynamic variables. In SIGPLAN '01 Conference
on Programming Language Design
and Implementation, pages 264-273, 2001.
[2] Bjarne Stroustrup. Exception safety: concepts
and techniques. In Advances in exception
handling techniques, pages 60-76.
Springer LNCS 2022, 2001.


Последний раз редактировалось mOleg Пн окт 06, 2008 18:07, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 05, 2008 05:58 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Данная статья меня заинтересовала потому, что сейчас я занимаюсь созданием структуры, разрешающей именно эту проблему:
надумалась конструкция DEMAND REJECT
вложенные обработчики ошибок.
Сама статья меня разочаровала, так как создает впечатления написанной на коленке за пару часов во время этого самого EuroForth 2008. Примеры и обоснования достаточно слабые ( я такого от Эртла не ожидал), но переводил и читал я статью одновременно, поэтому труд выкидывать не хочется.
За плохой перевод прошу ногами не пинать - перевод однопроходной, к тому же раздел "динамический контекст" очень сложно было переводить - dynamically scoped variables я в этой статье встретил впервые.


Последний раз редактировалось mOleg Вс окт 05, 2008 06:29, всего редактировалось 2 раз(а).

Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 05, 2008 06:13 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Теперь, насчет используемого примера с переменной BASE.
Решение предлагалось мною очень давно, и имеется в форке. Решение заключается в локализации переменной BASE, точнее создание локальной теневой копии такой переменной в USER области. Переменная инициализируется словом {# , которое аналогично слову <#, и определено следующим образом:
: {# ( base --> ) TO BASE@ SPAD-TOP HLD A! 0 HOLD ;
соответственно:
: <# ( --> ) BASE @ {# ;
что позволяет вообще не тревожить BASE по мелочам, а писать так:
... 0x10 {# #S #> ...
что сравнительно с классическим:
... BASE @ >R HEX <# #S #> R> BASE ! ...
выглядит значительно удобнее и проще и независимо от состояния переменной BASE получать необходимый результат. То есть глобальная переменная BASE вообще не затрагивается.
Но и это, как я только что понял не лучший вариант! Гораздо лучшим вариантом было бы размещение текущей системы исчисления в локальной переменной, или на стеке (возможно возвратов, возможно данных) таким образом, чтобы даже реально одновременно работающие # #S слова работали с локальными данными. Это решение на мой взгляд значительно лучше предлагаемых Эртлом.

Для сравнения:
Код:
: x. ( u BASE --> ) {# #S #> TYPE ;
: hex. ( u --> ) 10 x. ;       

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 05, 2008 06:22 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Что касается сборки мусора при работе с динамической памятью, то тут есть только один действительно решающий проблему метод: связывание всех используемых блоков в список, с подсчетом количества ссылок на блок, и периодический проход всего списка в поисках блоков, на которые никто больше не ссылается - то есть классическая Лисповская методика сборки мусора, причем я даже не представляю как к ее решению можно подойти в форте! Вроде бы постскрипт данную проблему решает, но все-таки он не очень близок к форту, чтобы запросто перенести решение.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 05, 2008 08:04 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
mOleg писал(а):
За плохой перевод прошу ногами не пинать


я и не пинаю, просто подсказываю бросающиеся в глаза места

mOleg писал(а):
Но даже в тогда были возможны не локальные выходы через ABORT и QUIT , так же как и через пользовательские прерывания. Если любые из этих нелокальных выходов или прерываний произойдут, BASE не будет восстановлена.
Таким образом, в раньше восстановление не могло быть произведено гарантированно.


подчеркнул нерусские конструкции, которые надо исправить...

mOleg писал(а):
Еффективность.


по-русски - Эффективность.

mOleg писал(а):
восстанавливаемые данные не могут быть прямо переданы через стека


через стеки - наверно


mOleg писал(а):
которые объясняют почему мы и другие использем ловлю исключений для реализации


mOleg писал(а):
Аналогично финализаторы в Яве выполняют освобождающий действия во время сборки мусора.



p.s. на счет описаной в статье "проблемы" - мне сказать нечего...
Сильно смахивает на проблему "как не вляпаться в кучу, которую соседская собака под моей дверью наклала?"

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 05, 2008 08:14 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
спасибо, WingLion, указанные ошибки исправил.

WingLion писал(а):
p.s. на счет описаной в статье "проблемы" - мне сказать нечего...
Сильно смахивает на проблему "как не вляпаться в кучу, которую соседская собака под моей дверью наклала?"

в некоторой степени это странно, так как проблема распространенная, например в плане закрытия файловых потоков, а так же освобождения блоков динамической памяти.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 05, 2008 08:51 
Не в сети
Administrator
Administrator
Аватара пользователя

Зарегистрирован: Вт май 02, 2006 13:19
Сообщения: 3565
Откуда: St.Petersburg
Благодарил (а): 4 раз.
Поблагодарили: 72 раз.
я так подозреваю, что эта проблема более проблема в многозадачном (многопотоковом?) режиме...

А в трой же винде - после закрытия программы ОС сама все файлы закрывает...
и никаких проблем после повторного вызова форт-программы не возникает.
(В DOS-е бывали затыки, а в WINDOWS-е я, во всяком случае, не сталкивался)

_________________
С уважением, WingLion
Forth-CPU . RuF09WE
Мой Форт
Отсутствие бана это не заслуга юзера, а недоработка модератора (с)


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Вс окт 05, 2008 19:19 
Не в сети
Аватара пользователя

Зарегистрирован: Пт май 05, 2006 06:19
Сообщения: 192
Благодарил (а): 0 раз.
Поблагодарили: 0 раз.
Какова проблема такова и статья.
Решение таких задачь является одной из основных целей программиста,
и желание вынести эту часть работы в некую уневерсальную автоматику позволяющую
"твори что хош и не парься" оно понятно, но бессмысленно.
Ибо рассматривать проблему на уровне языка в отрыве от операционной системы здесь просто не правильно.
Не представляется мне универсального одинаково успешного механизма
обойти все нюансы с занятием и освобождением памяти и файлов например для DOS, NT и *nix.
С переменной "BASE" (как в прочем и с предыдущим моментами) сооружать механизмы защиты её ...
ну фиг знает может таки проще сходу нарваться на проблему и пофиксить её самому и сразу.

_________________
SPF


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн окт 06, 2008 10:29 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
WingLion писал(а):
я так подозреваю, что эта проблема более проблема в многозадачном (многопотоковом?) режиме...

и да и не только. Даже в однозадачной ДОС системе может возникнуть прерывание. Например, мы хотим повесить обработчик, который следит за портом и выводит в числовом(текстовом) виде в файл с некоторой периодичностью (например по прерыванию). И есть у нас основная программа, которая тоже где-то выводит сообщения на экран. Теперь, допустим в файл мы пишем сообщения в 16ричной системе, а на экран в десятичной...

: обработчик ... Порт @ HEX <# #S #> вФайл ... ;

: вывод ... DECIMAL <# #S #> наЭкран ... ;

вот теперь вопрос, какими мы будет видеть числа в файле и на экране, особенно, если, прерывание произойдет в момент выполнения #S слова.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн окт 06, 2008 10:33 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
WingLion писал(а):
А в трой же винде - после закрытия программы ОС сама все файлы закрывает...

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

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн окт 06, 2008 10:50 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
mrack писал(а):
Какова проблема такова и статья.

Не совсем, обрати внимание, что механизм предлагается, причем простой на вид, а реализации еще нет.
Кстати, я не нашел больше ничего интересного вообще в материалах EuroForth2008 - остальные статьи еще большая муть! (или я что-то пропустил?)

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

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

Возвращаясь опять к статье, в ней ведь сразу три проблемы слиты воедино, поэтому и выглядит чудаковато

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн окт 06, 2008 11:27 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
mOleg писал(а):
: обработчик ... Порт @ HEX <# #S #> вФайл ... ;

: вывод ... DECIMAL <# #S #> наЭкран ... ;

вот теперь вопрос, какими мы будет видеть числа в файле и на экране, особенно, если, прерывание произойдет в момент выполнения #S слова.


В СПФ переменые HLD BASE PAD типа USER.
Т.ч. установив для прерывания регистр EDI c помощью TlsIndex!
никаких конфликтов не возникнет.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн окт 06, 2008 11:33 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Mihail писал(а):
В СПФ переменые HLD BASE PAD типа USER.
Т.ч. установив для прерывания регистр EDI c помощью TlsIndex!
никаких конфликтов не возникнет.

Михаил, пример с BASE несколько дутый, да и речь не только об СПФе.
К тому же, в СПФе это тоже не всегда спасает, например найти можно такой код запросто:
BASE @ >R HEX DUP U. R> BASE !
что очень даже коряво выглядит, о чем и речь, и потенциально опасно, потому что может быть такой код:

: blabla. .. ;
: .bla BASE @ >R HEX blabla. R> BASE ! ;

... ['] .bla CATCH DROP ...

то есть BASE в текущем потоке вдруг может нежиданно оказаться не в том состоянии


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн окт 06, 2008 11:50 
Не в сети

Зарегистрирован: Ср май 03, 2006 11:27
Сообщения: 1394
Откуда: St.Petersburg
Благодарил (а): 2 раз.
Поблагодарили: 11 раз.
mOleg писал(а):
например найти можно такой код запросто:
BASE @ >R HEX DUP U. R> BASE !


Ну коректнее

BASE @ >R HEX DUP ['] U. CATCH R> BASE !
THRUW

Можно исправить, но можно и пренебречь.


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
 Заголовок сообщения:
СообщениеДобавлено: Пн окт 06, 2008 11:53 
Не в сети
Moderator
Moderator
Аватара пользователя

Зарегистрирован: Чт май 04, 2006 00:53
Сообщения: 5062
Откуда: был Крым, теперь Новосибирск
Благодарил (а): 23 раз.
Поблагодарили: 63 раз.
Mihail писал(а):
Ну коректнее

BASE @ >R HEX DUP ['] U. CATCH R> BASE !

THROW

Можно исправить, но можно и пренебречь.


да, конечно же ;) об этом в статье и идет речь.
Просто прикол в том, как по мне, что сам CATCH механизм теперь стал причиной рассматриваемой проблемы.
И еще остается проблема восстанавливания многих переменных, что уже не решается приведенным тобой примером.

_________________
Мне бы только мой крошечный вклад внести,
За короткую жизнь сплести
Хотя бы ниточку шёлка.
fleur


Вернуться к началу
 Профиль Отправить личное сообщение  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 18 ]  На страницу 1, 2  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 21


Вы не можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
phpBB сборка от FladeX // Русская поддержка phpBB