Тишина...
Так как по трем действительно интересным письмам за всю неделю итоги составлять несколько тухло, то мне ничего не остается делать, как процитировать интереснейшее письмо Димитрия Федотова. Конечно, группа его уже видела, но вот Open3OS это может взбодрить.
Да и своим полезно лишний раз капнуть на мозг. )
Краткое содержание предыдущей серии by Freeman:
Надеюсь, многие знают, что такое TObject в Delphi. Это некий набор низкоуровневых сервисов, позволяющий управлять экземплярами классов во время выполнения программы. Получается, что объект Дельфи - это одновременно и единица программирования, и некоторая сущность времени выполнения, доступная через TObject. Сам TObject частично прошит в компилятор, поэтому создание классов Дельфи без TObject невозможно. Кстати, поэтому скомпилированные программы на Дельфи занимают такой большой размер, поскольку, по сути, содержат в себе полноценную подсистему управления классами и объектами во время выполнения.
Поддержка TObject настолько серьезная, что для реализации COM в Дельфи потребовалось добавить совсем немного кода.
Почему я завел разговор про TObject. Мне кажется, что сервис УО в 3ОС надо спроектировать подобным образом. Например, синхронный или транзакционный вызов метода для конкретного объекта будет доступен только, если сам объект с точки зрения среды выполнения будет представлять собой некоторый обьект времени выполнения. Управление этим объектом будет производиться через методы, предоставляемые c_RemoteObject - аналог TObject в Дельфи.
И, собственно, самое главное:
Предлагаю свое решение этой проблемы. Для начала изложу определения элементов ООП относительно ОС.
КЛАСС - это набор методов. Или в терминах процессора это сегмент кода.
ОБЪЕКТ. Использует сегмент кода определенный в классе, и определяет свой сегмент данных.
ПОТОК. Потоком можно назвать стек вызовов (Call Stack). Если к примеру мы создаем объект в системе и запускаем его, то в стек вызовов попадает первый вызов метода Main. Этот метод по ходу выполнения вызывает какой-нидь метод другого объекта. Следовательно в стек данного потока попадает вызов этого, другого, метода.
ВЫЗОВ - рабочая лошадка. Для его надо определить свой стек. В рамках вызовов происходит вся работа системы. С точки зрения процессора это задача (task). Вызов содержит информацию о классе (сегмент кода), о объекте, чей метод вызываем (сегмент данных) и о потоке (кто вызывает).
Так как каждый вызов переключает задачу (сегмент кода, сегмент данных и стек), то получается объекты защищены друг от друга.
Как находить объекты, вызывать методы - дело системных вызовов. Мне кажется это достаточно очевидным.
Если немного расширить понятие ВЫЗОВ, то можно с его помощью вызывать методы объектов, находящиеся хоть в другом измерении - был бы канал связи.
И
Предлагаю подумать в этом направлении.
Удачи.
Добавил Roman I Khimov | Читать/Отправить комментарии: 0
|