OberonCore

Как бы она это делала в чужом процессе?))) ведь это не стек а2.

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

мы о каких-то разных колбэках говорим. Я имею ввиду процедуры а2, которые регистрируются в нижележащей ОС и которые эта ОС вызывает когда ей вздумается. Конечно, ОС вызывает эти процедуры из своих процессов, у которых свой стек. Этот стек и использует колбэк.
Решение для учета ссылок в колбеках на самом деле в а2 есть. Это барьеры записи. В основной версии а2 они простые но быстрые, в кооперативной сложнее и совершаются дополнительные телодвижения, например подсчет ссылок для локальных указателей, для выявления утекших за пределы процедуры. В основной версии а2 этого пока нет.
Так вот, локальные указатели помещаются в специальный список и исключаются из него при выходе из процедуры, если количество ссылок равно нулю, то есть они точно локальны и память можно освободить даже не обращаясь к сборщику. В основной версии указатели попадают в такой список только если у экземпляра есть поля или элементы ссылочного типа и требуется их обработка для маркировки в основном цикле. Дальше они обрабатываются сборщиком.
Здесь нужно кое что доделать для колбэков и завернуть в FINALLY, чтобы гарантированно потом освободить все ссылки.

Спасибо за ответ. Раз уж я слазал в исходники ЯОС, то вот код этой процедуры:

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


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


Ну вот, и обёртка нашлась, правда не та, которую мы искали. Вот код этих функций в ЯОС:


Она вставляется не в функции обратного вызова, а в функции "прямого" вызова, когда собранная как приложение A2 (в данном случае ЯОС) вызывает библиотечную функцию ОС.

а я имею в виду гипотетический API типа такого:

куда в качестве cback передаётся обероновская процедура, и `enum_resources()` её из себя в цикле вызывает, например. а саму `enum_resources()` вызывает другая обероновская процедура.

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

я, по ходу, тут подумал очевидное: феноменальная стабильность BBCB в немалой степени следствие того, что в нём нет потоков. и хотя иногда их иметь приятно, и я всё ещё не бросил идею частично затащить в LC ActiveBB, но чем дальше — тем меньше мне эта идея нравится. я слишком тупой, чтобы писать хороший многопоточный код.

кстати, есть альтернативный вариант: организовать несколько независимых процессов BBCB внутри одного адресного пространства. эти процессы могут совместно использовать модули (но каждый процесс будет иметь свою копию глобальных переменных модуля), но не могут обмениваться указателями. если надо передать какому-то процессу данные — только через почтовый API, который организует копирование. или через специальный объект, который внутри себя держит ровно один указатель на данные и информацию о процессе-владельце (и выделяется это в отдельной области памяти).

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

наличие общего адресного пространства позволит быстрее обмениваться данными, чем через IPC, поэтому так. конечно, обмениваться напрямую указателями нельзя (и внутри данных тоже), так что в принципе почтовому API всё равно, в одном АП ли процессы. так что в теории потом можно реализвать полноценные процессы в разных АП так, что уже написаный код ничего не заметит. да хоть по сети маршалить.

надо над этой идеей помедитировать: чую я в ней нечто хорошее, годное. правда, сразу непонятно, например, что делать с трапами в процессах, у которых нет своих окон. надо будет каким-то образом маршалить информацию о трапе в «главный» процесс, и иметь ядерный API, позволяющий исследовать память других процессов. в принципе, тоже решаемо, но не с напрыгу.

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

как будет вдохновение — попробую сделать PoC. если всё пойдёт так хорошо, как я себе воображаю — то внесу в LC как официальную фичу тогда.

Этой идее сто лет в обед, в частности, некоторые хотели сделать "несколько блекбоксов внутри A2", но всё так на обсуждениях и закончилось. Внезапно, в обычных ОС типа Win/Lin так и работают несколько Java-машин, в браузере так работают несколько окон и т.п. И прекрасно совмещается возможность работы программ, написанных со сборкой мусора, и без, питон и ассемблер, локализация повреждения кучи, автоматическое освобождение ресурсов, масштабирование кучи на мелкие подкучи, бригады работяг (пулы воркеров).

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

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

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

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

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

Ну и плюс к тому, здесь можно найти тему, когда я спрашивал про TLS (thread local storage). TLS - это по сути дела хороший шаг к тому, чтобы каждый поток владел своими данными и тем самым конфликты параллельности для этих данных становятся невозможными по построению. Отслоив эти данные, можно сильно ограничить объём разделяемых между потоками данных. Если в этом направлении идти достаточно далеко, можно и до почтовой системы дойти, если это нужно. Местные снобы написали мне, что я ничего не понимаю и что TLS не нужен (в A2), потому что там есть активные объекты. На самом деле это они сами ничего не понимают и это вряд ли можно вылечить. В других культурах тоже плохо относятся к TLS. Ну и пускай. Пусть победа роботов над людьми не приближается.

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

https://github.com/goldsborough/ipc-bench

Насчёт внезапного прихода GC не стоит особо обольщаться. Если у тебя есть N независимых "работяг", и к одному из них пришёл GC, то он на время GC ничего делать не будет. Если ты построил из них конвейер, то будет задержка во всём конвейере. А дальше простой для меня пример цифровой музыкальной студии с плагинами. Суммарная задержка в тракте должна быть минимальной. 5 мс - это всё ещё повод для совершенствования. А количество операций над звуком от входа до выхода может достигать десятка (микширование и обработки). Если взять N ББЦБ и в каждом из них написать алгоритм со сборкой мусора, то это всё в целом работать не будет. А если посмотреть программы типа Cakewalk или Pro Tools, то мы увидим там жирнючий ГУЙ, который в оберон-культуре принято писать на куче со сборкой мусора. В общем, есть над чем задуматься (делить обработки на графическую и неграфическую часть, смириться с тем, что отрисовка звука будет лагать и т.п.)

Кроме того, понадобится планировщик задач, команды типа ps и kill. В итоге всё равно получится A2 или другая операционная система
Написать планировщик задач - непросто. Либо нужно приостанавливать каждый ББЦБ в произвольной точке, как в вытесняющей многозадачности - это нетривиальная задача из-за взаимодействия с периферией, и может быть ещё из-за чего-то (я помню, что это сделать сложно или нельзя, но не помню, почему). Либо делать кооп. многозадачность - это снижение стабильности и возникновение неявных взаимодействий. Либо ещё что-то. В любом случае, процессы не будут полностью изолированными и нужно будет следить за тем, как они конкурируют за вычислительные ресурсы, управлять этой конкуренцией.

это да, я и не претендую на то, что придумал что-то новое. просто вспомнил то, что придумали до меня, и очень обрадовался. ;-)

потоки/активности — тоже добавление этажа, которого не было.

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

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

технически это просто способ избежать дублирования кода в памяти. то есть, вместо загрузки в каждый «поток-процесс» модулей с нуля — каждому создаём отдельный сегмент данных. фича приятная, но не жизненно необходимая (как минимум в той схеме, которую я хочу сделать).

в принципе, если активность все свои данные держит внутри себя и не публикует наружу — то TLS действительно не очень нужно. ну, может чуть-чуть облегчить реализацию схемы «каждой активности свою кучу», но поскольку в A2 активностям не запрещено обмениваться указателями, то даже в этом особого смысла нет. я специально по этой причине обмен указателями делать не планирую, только специальными объектами, которыми можно оперировать исключительно через райдеры.

и все они приходят к тому, что быстрее всего иметь разделяемую область памяти и API для работы с ней. что я, в принципе, и реализую, только без специальных трюков с системными вызовами (но с трюком бутстрапа нового псевдопроцесса, да; однако это чисто обероновский трюк, независимый от ОС).

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

конкретно такую задачу я буду решать, когда она у меня возникнет. я ж не претендую на решение типа one size fits all. вполне вероятно, что я для чего-то подобного вообще не буду писать алгоритмы обработки на BBCB, а буду использовать BBCB чисто в качестве высокоуровневого клея. я не настолько фанатик, чтобы «или всё на BBCB, или ничего мне не надо!» ;-)

BBCB и есть операционная система. ;-) ну подумаешь, она пытается этот факт спрятать. честно говоря — не очень сильно и пытается.

так мне не надо его писать, у меня для этого host OS есть.

мне вполне достаточно того, что язык не позволит написать код, который нагадит в чужой горшочек. это обеспечивает достаточную изоляцию. приоритеты «потокам-процессам» спокойно назначаются через host OS. а управление ресурсами — это уже задача программиста. у меня будет механизм, который позволит использовать все ядра CPU, и простой API для обмена сообщениями — а остальное строится по необходимости поверх этого. нахождение таких «псевдопроцессов» в одном АП просто облегчает передачу между ними большого объёма данных (по сути, это сводится к передаче одного объекта-хэндла).

собственно, мне в компиляторе надо будет только одно маленькое изменение сделать, чисто во фронтэнде: добавить к VAR-параметрам флажок `[nopts]`. чтобы гарантировать, что API обмена сообщениями не получит на вход фигню с указателями, а не проверять это руками каждый раз.

увидел в интернетах идею и подумал, что надо обязательно украсть: режим «caps word» для редактора. когда активирован — все вводимые символы капсятся, пока не двинули каретку, или не ввели что-то, что не буквоцифра (и не подчёркивание). активируется, натурально, спецкомандой из меню (повешаной на Ctrl+Space). если справа или слева от каретки слово — его закапсят. а если нет — то врубится режим «caps word».

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

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

а никак не надо. мне для моих задач хватит системного kill(2), чтобы туда сигнал послать. ты учитывай, что у меня есть некоторый круг задач, под которые такая простая система отлично подходит. вот ничего свыше этого я делать и не буду, пока мне оно не понадобится позарез. мне вообще нужны штуки типа «играем музыку на фоне при помощи OpenAL и libxmplite», «просчитываем визуализацию по тайлам» и подобное. для этого с головой хватит: раз отладил — и оно работает. на крайний случай послал туда какой-нибудь SIGTRAP, оно померло.

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

вот! вот это правило, да. я его пытаюсь соблюдать. потому что всегда страдаю овергенерализацией, и пытаюсь сделать что-то чтобы Большое, Универсальное, На Все Случаи. с закономерным результатом. в LC пытаюсь с этим бороться, и делать исключительно простые небольшие кусочки, которые сразу использовать можно. надеюсь, получится. ;-)

пол-года собирался, и наконец-таки сделал undo/redo в editor control. сам не знаю, зачем: мне оно особо и не надо. но пусть будет, надо ж чем-то бесполезным в память гадить.

p.s.: это я, конечно, начал делать спавнер процессов в том же АП. а получилось undo/redo в editor control. неисповедимы, очень загадочны эти пути.

кстати, в Fonts не хватает полезного API: «а посчитай-ка мне, сколько символов из строки влезет в данную ширину». понятно, что это можно и в цикле руками сделать, но бэкэнд подобную считалку может сильно заоптимайзить. например, мой бэкэнд для X11 считает ширину строки посимвольно, так что там несложно просто остановиться в нужный момент. виндобэкэнд тоже делает что-то похожее, но я не понимаю, что там за куча таблиц и зачем они нужны, так что туда пока воткнул просто цикл.

кстати (лень проверять, писал ли уже): разрешил в текстах один комбайн: acute accent. так-то LC просто отфильтровывает нафиг все юникодовые комбайны, и печатает вместо них «плохой символ» (квадратик, или знак вопроса). потому что я считаю, что комбайны — идиотская идея (как и весь юникод, впрочем). ударение тоже должно быть не комбайном, а набором глифов с пририсованым ударением, но фиг с ним: сделал исключение, потому что использую LC в том числе и для простого набора текстов, и там иногда нужно ударение ставить так, как ожидают ударение некоторые другие софтины.

редактор, если что, вполне нормально с такими извращениями справляется, и всегда справлялся. ну, насколько вообще можно нормально справляться с подобной фигнёй — то есть, приемлемо.