OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 25 Апрель, 2024 11:41

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 62 ]  На страницу Пред.  1, 2, 3, 4  След.
Автор Сообщение
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:12 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
Я не вижу смысла дальше обсуждать, так как это какое-то упорное непонимание моей мотивации. Если бы вам было интересно, то поняли бы, что я совершенно точно апологет бинарных форматов Блэкбокса. Не тратьте усилия, правда.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:14 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
adimetrius писал(а):
В приведенном вами примере заложена мина.
f := Files.dir.Old(..., Files.shared);
...
f.Close

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

Не стоит проверять существование файла таким образом. Стоит писать процедуру FileExists и пользоваться File.dir.FileList.

Не может такое привести к АВОСТУу.


Последний раз редактировалось Борис Рюмшин Пятница, 30 Декабрь, 2022 18:43, всего редактировалось 1 раз.
Сообщение исправлено по просьбе автора.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:42 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1167
Иван Денисов писал(а):
Я не вижу смысла дальше обсуждать, так как это какое-то упорное непонимание моей мотивации. Если бы вам было интересно, то поняли бы, что я совершенно точно апологет бинарных форматов Блэкбокса. Не тратьте усилия, правда.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:49 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван Денисов писал(а):
Не может такое привести к АВОСТУу.


А как же
Цитата:
PROCEDURE (f: File) Close
NEW, ABSTRACT
Closes an open file. ...
The file f and the riders operating on file f are not valid anymore after closing f, i.e., no more file or rider operations may be performed on it. ...


Проверил соответствие реализации интерфейсу.
Код:
   PROCEDURE Landmine*;
      VAR f, g: Files.File; rd: Files.Reader; b: BYTE;
   BEGIN
      g := Files.dir.Old(Files.dir.This('/tmp'), 'landmine', Files.shared); ASSERT(g # NIL);
      rd := g.NewReader(NIL);
      f := Files.dir.Old(Files.dir.This('/tmp'), 'landmine', Files.shared);
      f.Close;
      rd.ReadByte(b) (* 1 *); rd.SetPos(0) (* ! *); rd.ReadByte(b)
   END Landmine;


Интерфейсу соответствует SetPos - падает в отмеченном месте. ReadByte (* 1 *) не падает, хотя должен. Полагаю, ReadByte упадет еще позже, и еще сложнее будет найти причину.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:51 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
Я сам файл открыл, сам закрыл. После закрытия я этот файл не читал. Что тут может привести к АВОСТу?
Это серьезное дело, если вы где-то файлы не закрываете, из расчёта, что это может как-то навредить другим файлам, то это может приводить к тому, что сборщик не утилизирует временные файлы, или ещё к каким-то последствиям. Смело закрывайте файлы, которые сами открыли. Вы не можете никак навредить другим экземплярам открытых файлов. Они ведь в shared режиме.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:52 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Это же модульная система, а не монолитная.
Цитата:
Если вдруг окажется, что кто-то где-то до вас открыл этот же файл


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 14:55 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Напротив, в открытой модульной системе закрывать файл (открытый в shared режиме) можно только в исключительных случаях, например, когда вы точно знаете, что это вы же его создали, и пока вы им пользовались, никто другой (т.е. никакой другой модуль) гарантированно его не открыл. (Хотя достоверно это можно знать только про анонимные файлы). А в остальных случаях - на свой страх и риск.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 15:01 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
Посмотрел ваш пример, и правда падает! На мой взгляд, какая-то дичь.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 15:02 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
adimetrius писал(а):
Напротив, в открытой модульной системе закрывать файл (открытый в shared режиме) можно только в исключительных случаях, например, когда вы точно знаете, что это вы же его создали, и пока вы им пользовались, никто другой (т.е. никакой другой модуль) гарантированно его не открыл. (Хотя достоверно это можно знать только про анонимные файлы). А в остальных случаях - на свой страх и риск.

Спасибо за разъяснение — это очень ценно.

Ну и надо бы как-то документировать это получше. А то там написано, что лучше вызывать Close, и это прям сбивает с толку.
Цитата:
If it is known that a file won't be used again, it is recommended to call its Close procedure.

И еще:
Цитата:
Close should (but need not necessarily) be called explicitly after a file is not needed anymore.



Я всегда закрывал файлы, чтобы кэш на диск сбросился и сборщик собрал лишнее. К проблемам это, к счастью пока не приводило. Однако могло. Буду умнее впредь :)

Обновлённый пример. Закрывать файл не обязательно. Ну и я считаю, что вполне правомерно проверять файлы на их существование открытием.
Код:
MODULE EasyLibrarian;
(**
   project   = "BlackBox 2.0"
   organization   = "www.oberon.ch, blackbox.oberon.org"
   contributors   = "Ivan Denisov"
   version   = "System/Rsrc/About"
   copyright   = "System/Rsrc/About"
   license   = "The 2-Clause BSD License"
   changes   = ""
   issues   = ""

**)

   IMPORT Files, DevCPM, StdLibrarian;

   TYPE
      Librarian = POINTER TO RECORD (StdLibrarian.Librarian)
         root: Files.Locator
      END;

   PROCEDURE (lib: Librarian) GetSpec (IN sub, name: ARRAY OF CHAR; what: INTEGER; OUT loc: Files.Locator; OUT fname: Files.Name; OUT ftype: Files.Type);
   VAR f: Files.File; loc2: Files.Locator;
   BEGIN
      loc := lib.root.This(sub);
      CASE what OF
      | StdLibrarian.source:
         loc := loc.This('Mod');
         IF loc.res = 0 THEN
            loc2 := loc;
            f := Files.dir.Old(loc2, name + ".cp", Files.shared);
            IF loc2.res = 0 THEN
               ftype := "cp";
            ELSE
               ftype := "odc"
            END;
         ELSE
            ftype := "odc"
         END;
         fname := name$
      | StdLibrarian.symbols: loc := loc.This('Sym'); ftype := 'osf'; fname := name$
      | StdLibrarian.code: loc := loc.This('Code'); ftype := 'ocf'; fname := name$
      | StdLibrarian.docu: loc := loc.This('Docu'); ftype := 'odc'; fname := name$
      | StdLibrarian.moddocu: loc := loc.This('Docu'); ftype := 'odc'; fname := name$
      | StdLibrarian.rsrc: loc := loc.This('Rsrc'); ftype := 'odc'; ; fname := name$
         (* not sure... how 'bout arbitrary resources? *)
      ELSE HALT(20)
      END;
      lib.res := StdLibrarian.OK
   END GetSpec;

   PROCEDURE Set*;
   VAR lib: Librarian;
   BEGIN
      NEW(lib);
      lib.root := Files.dir.This("");
      StdLibrarian.SetLib(lib);
      DevCPM.lib := lib;
   END Set;

END EasyLibrarian.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 16:39 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1449
Откуда: Киев
Иван Денисов писал(а):
Посмотрел ваш пример, и правда падает! На мой взгляд, какая-то дичь.
Верно - дикость. Налицо неправильное воплощение открытия файла. Из приведённой документации никак не следует и, главное, не должно следовать, что при закрытии файла должны стать негодными структуры, связанные с независимым открытием этого же файла.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 16:52 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
Я что-то пока шел на свежем воздухе от офиса домой, я тоже размышлял и понял, что Антон сделал прекрасный пример для демонстрации ошибки реализации... Надо поправить, ИМХО. Так не должно работать...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 17:08 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Отмечу, что такая же "дикость" наличиствует в А2, поскольку тянется из системы Оберон (хотя голову не дам на отсечение).

Припоминаю, что тоже был в шоке, когда первый раз с этим столкнулся. Это не ошибка реализации, это как раз в точности исполненная реализация, но только в SetPos. А в ReadByte нет. У вас же перед глазами документация, не правда ли?

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

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

Вообще не вижу необходимости вызывать Close. Даже при создании нового файла: при его регистрации Register сама сохранит все буферы, закроет файл, и тем самым сделает его далее непригодным к использованию (до следующего Open).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 17:16 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван Денисов писал(а):
Это серьезное дело, если вы где-то файлы не закрываете, из расчёта, что это может как-то навредить другим файлам, то это может приводить к тому, что сборщик не утилизирует временные файлы, или ещё к каким-то последствиям.


Временные файлы в ББ анонимны, создаются Files.dir.Temp(), они в относительной безопасности, поскольку доступ к ним могут получить только те, кому вы лично вручите указатель на файловую переменную.
Про любые файлы: как только вы утратили указатель на файл (временный, именованный, монопольный, общий, для записи), сборщик мусора вызовет FINALIZE и оттуда - Close, так что на счет утечки ресурсов не надо бепокоиться. Гораздо опаснее, если у вас где-то притаился указатель на файловую переменную. В этом случае невозможно получить доступ к изменившемуся содержанию файла на диске.

Отмечу явно, что
f := Files.dir.Old(loc, fname, Files.shared);
g := Files.dir.Old(loc, fname, Files.shared);
ASSERT(f = g, 100)

Т.е. с одним файлом в хранилище связана одна или не связано ни одной файловой переменной; двух не может быть. (Указателей, конечно, сколько угодно можно насоздавать).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 20:29 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
adimetrius писал(а):
Отмечу явно, что
f := Files.dir.Old(loc, fname, Files.shared);
g := Files.dir.Old(loc, fname, Files.shared);
ASSERT(f = g, 100)

Кстати, вот это бы можно было тоже добавить в документацию. Тогда и .Close становится понятнее. Что он применяется ко всем объектам разом. А точнее, что объект-то один.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 21:41 

Зарегистрирован: Четверг, 08 Май, 2008 19:13
Сообщения: 1449
Откуда: Киев
adimetrius писал(а):
Припоминаю, что тоже был в шоке, когда первый раз с этим столкнулся.
Это только подтверждает, что это дикость.

Цитата:
Это не ошибка реализации, это как раз в точности исполненная реализация, но только в SetPos. А в ReadByte нет.
У вас же перед глазами документация, не правда ли?
Перед глазами, и Вы слишком вольно её интерпретировали. Уже начиная с того, что не могут быть выполнены не является при вызове будут падать.

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

Цитата:
Вообще не вижу необходимости вызывать Close.
Если бы это было так, то Close и не должно было быть доступно, и все средства для этого есть.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 21:55 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3776
Иван Денисов писал(а):
adimetrius писал(а):
Отмечу явно, что
f := Files.dir.Old(loc, fname, Files.shared);
g := Files.dir.Old(loc, fname, Files.shared);
ASSERT(f = g, 100)

Кстати, вот это бы можно было тоже добавить в документацию. Тогда и .Close становится понятнее. Что он применяется ко всем объектам разом. А точнее, что объект-то один.

А может ли такое быть, что когда-то в Оберон микросистемс это сделали для экономии памяти? И теперь мы просто страдаем от побочных эффектов такого решения?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 21:58 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Додумался, когда нужен Close: когда вы монопольно почитали файл и готовы вернуть в общее пользование.

После слов "The file f and the riders operating on file f are not valid anymore after closing f" я, да, готов к авосту. Пользоваться тем, что not valid - это аварийная ситуация.
А вот, пожалуй, неполнота Files заключается в том, что невозможно выяснить, что файл или читатель стали not valid, и это вот неправильно. Т.к. клиенту невозможно предотвратить аварийное обращение.

Если вы предлагаете менять, предложите пж более весомые доводы, чем "это дикость; если вы удивились - тем более это дикость".

И, кстати, когда я знакомился с Обероном (языком и системой), то и дело удивлялся. Анонимные файлы - тоже удивительаня весчь. Мои мейнстримовые однокурсники и коллеги тоже немедленно объявляют это дикостью, как только услышат.

Вот я полагаю, что можно поменять в документации, написать типа "Close предназначена для закрытия монопольно открытых файлов. В остальных случаях закрывать файлы не нужно, привычка вызывать file.Close - это профдеформация из мейнстрима".
Еще вариант на обдумать - вообще запретить Close для немонопольных файлов, т.е. делать аварийный останов в иных случаях.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 22:06 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1167
adimetrius писал(а):
Анонимные файлы - тоже удивительаня весчь. Мои мейнстримовые однокурсники и коллеги тоже немедленно объявляют это дикостью, как только услышат.
они никогда не работали с unix-системами? ведь один из очень широко используемых паттернов (хоть и был реализован криво на уровне ОС): создать временный файл, и тут же его удалить, не закрывая. файл есть — а имени больше нет.
adimetrius писал(а):
Еще вариант на обдумать - вообще запретить Close для немонопольных файлов, т.е. делать аварийный останов в иных случаях.
поддерживаю. если надо скинуть данные на диск — есть `Flush`.

p.s.: маленький нюанс: теоретически `close 2` может тоже завершиться с ошибкой, и программа упадёт в рандомном месте неизвестно от чего. правда, на практике я ни разу не видел в коде, чтобы кто-то проверял результат этого системного вызова.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 22:25 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван Денисов писал(а):
А может ли такое быть, что когда-то в Оберон микросистемс это сделали для экономии памяти? И теперь мы просто страдаем от побочных эффектов такого решения?


При встрече с чрезвычайно плохой новостью психика сначала реагирует шоком, потом отрицанием, потом торгом. :)

Такое поведение алгоритмически очень дорого обходится. Во-первых, оно требует финализаторов (в языке). Во-вторых, в Kernel целое хозяйство для этого заведено: тип Identifier, типовая процедура Identified, процедура ThisFinObj. Ядро ведет ведомость всех записей (не типов!) с финализаторами (т.е. в каком-то смысле держит на такие записи "мягкие ссылки", которые невидимы для мусорщика. Упомянутые средства ядра позволяют найти запись в этой ведомости, т.е. воспользоваться мягкими ссылками) - одним словом, явные следы целеполагания и планирования, выходящего за рамки задачи экономии памяти. Взгляните, напр, как устроена LinFiles.ThisFile.

Коллеги, это не дико, это удобно. Как сборка мусора. Только для файлов. В конце психика адаптируется - привыкает :)


Последний раз редактировалось adimetrius Четверг, 29 Декабрь, 2022 22:26, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Портирование VisualOberon под Ofront+
СообщениеДобавлено: Четверг, 29 Декабрь, 2022 22:26 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
arisu писал(а):
создать временный файл

- разве это не потребует имени?


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

Часовой пояс: UTC + 3 часа


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

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


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

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB