Перейти к публикации
Форум - ComputerCraft
RccHD

Разработка новой операционной системы. WinOS.

Рекомендованные сообщения

Чтобы бы там не говорил Fingercomp по поводу написания своих ОС, я таки пишу свою ОС :)

Планы такие:
1) разработать операционку с многозадачностью на основе OpenOS с полной совместимостью
2) запуск нескольких программ одновременно(в том числе графических)
3) возможность разбивки экрана на прямоугольные зоны для предоставления программам доступа к этим зонам(программы не будут рисовать графику вне предоставленной зоны)
4) буферизация графики с ускорением отрисовки (как у ECS). Я не стал брать либу от ECS потому что она использует другие либы того же автора и потому что реализована эта библиотека довольно коряво в плане стиля написания кода(мое личное мнение). В общем, я переписал либу ECS с нуля под нужды операционки, кол-во кода сократилось в 5 раз. Все программы написанные на моей OC будут иметь "графическое ускорение" по умолчанию.

Пункты 2 и 3 фактически уже закончены(по-крайней мере мне так кажется)
Буферизация(пункт 4) работает прекрасно, отрисовка графики в некоторых случаях может быть в 3-15 раз быстрее(относительно gpu api)

Также планируется написать несколько очень простых программ для демонстрации возможностей ОС
В частности, хочу реализовать ОЧЕНЬ сильно урезанную реализацию моего любимого оконного менеджера xmonad


Важно: все OpenOS-программы можно будет запустить на моей OC

Изменено пользователем Alex

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Надеюсь, что мне не надоест разрабатывать эту OC, иначе будет еще одна R.I.P операционка

Планирую закончить разработку максимум через месяц. По истечении этого времени, я либо выложу готовый результат/альфа-версию, либо забью на разработку

 
P.S. я школьнег и мне кроме написания OC еще учиться надо :)

Изменено пользователем RccHD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Также планируется написать несколько очень простых программ для демонстрации возможностей ОС

Важно: все OpenOS-программы можно будет запустить на моей OC

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

 

Основные проблемы:

* Кооперативная многозадачность потребует обязательной доработки запускаемых программ. А в случае подвисания одной из программ подвиснет вся система.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

* Кооперативная многозадачность потребует обязательной доработки запускаемых программ. А в случае подвисания одной из программ подвиснет вся система.

Программы, запускаемые многозадачно, вовсе не обязаны быть ориентированными на многозадачность. Здесь я показывал вариант как можно реализовать такую многозадачность. Вот с подвисанием согласен.

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

Оборудование доступно программам через объект component. Если система подменит этот объект своим, то она сможет разруливать аппаратные коллизии. Например, если одна программа использует редстоун-карту, то другой программе можно не давать к ней доступ.

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну, если пост Фингера прочитан, все риски взвешены, план битвы составлен и мосты сожжены - желаю удачи =)

Посмотрим, что получится.

  • Like 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
блиотека довольно коряво в плане стиля написания кода(мое личное мнение)

 

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно  :wacko:

 

А вообще интересно, каким образом ты уменьшил размер сырцов в 5 раз - уж не путем ли удаления половины "не нужных" для твоей ОС элементов? Го инфу, любопытно стало.

Изменено пользователем ECS
  • Like 4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Оборудование доступно программам через объект component. Если система подменит этот объект своим, то она сможет разруливать аппаратные коллизии. Например, если одна программа использует редстоун-карту, то другой программе можно не давать к ней доступ.

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

 

Поэтому данное утверждение не соответствует действительности:

Важно: все OpenOS-программы можно будет запустить на моей OC

«Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

«Все» программы придется сначала адаптировать к новой OS, а это уже заметный недостаток.

Во, первых это ты сам решил что "все программы придется адаптировать", я такого не писал :)

Я постараюсь написать такую ОС, на которой можно будет запустить большинство программ без доработки

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну блин, стараешься тут, стараешься, разбивая код на суб-сегменты по классическим идиомам проектирования, минимизируя нагрузку на оперативку и ЦПУ, а потом его "корявым" называют. Обидно  :wacko:

 

А вообще интересно, каким образом ты уменьшил размер сырцов в 5 раз - уж не путем ли удаления половины "не нужных" для твоей ОС элементов? Го инфу, любопытно стало.

По поводу моей субъективной оценки твоего кода:

 

Я вот такие вещи вообще видеть не могу, это вообще не по-человечески так писать:

changes[buffer.currentFrame[index]] = changes[buffer.currentFrame[index]] or {}
changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] = changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]] or {}
				
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], x)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], y)
table.insert(changes[buffer.currentFrame[index]][buffer.currentFrame[indexPlus1]], table.concat(sameCharArray))
				

 

Когда я вижу подобный код, я начинаю думать:

1) У автора этого кода паническая боязнь переменных(или он проспорил кому-то)

2) Автор думает, что любая созданная переменная занимает гигабайты в оперативке, поэтому их не использует

3) У автора Крутой Продвинутый Текстовый Редактор ™, который позволяет написать "buffer.currentFrame[index]" сразу в трех местах

 

 

Так как я не фанат различных навороченных редакторов текстовых редакторов и не боюсь переменных и знака "=", я бы написал этот код вот так:

 

local el0 = buffer.currentFrame[index],
      el1 = buffer.currentFrame[indexPlus1]

changes[el0] = changes[el0] or {}
changes[el0][el1] = changes[el0][el1] or {}
				
table.insert(changes[el0][el1], x)
table.insert(changes[el0][el1], y)
table.insert(changes[el0][el1], table.concat(sameCharArray))
				

По поводу нагрузки на ЦПУ:

писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия:

1) получает значение переменной "buffer"

2) получает поле "currentFrame" объекта "buffer"

3) получает поле "index" объекта "buffer.currentFrame"

 

А если хранить это значение в переменной, то будет одно действие:

1) получает значение переменной "el0"

Изменено пользователем RccHD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По поводу нагрузки на ЦПУ: писать "buffer.currentFrame[index]" плохо так как система будет каждый раз выполняет следующие действия: 1) получает значение переменной "buffer" 2) получает поле "currentFrame" объекта "buffer" 3) получает поле "index" объекта "buffer.currentFrame" А если хранить это значение в переменной, то будет одно действие: 1) получает значение переменной "el0

 

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

Всегда считал, что переменные(они же указатели на объекты) не могут занимать много памяти...

 

Хотя бы потому что исходники библиотек OpenOS прямо-таки напичканы переменными. Может дело все-таки не в таких мелочных деталях как переменные, а в самой реализации?

 

 

function buffer:readLine(chop, timeout)
  self.timeout = timeout or (computer.uptime() + self.readTimeout)
  local start = 1
  while true do
    local buf = self.bufferRead
    local i = buf:find("[\r\n]", start)
    local c = i and buf:sub(i,i)
    local is_cr = c == "\r"
    if i and (not is_cr or i < #buf) then
      local n = buf:sub(i+1,i+1)
      if is_cr and n == "\n" then
        c = c .. n
      end
      local result = buf:sub(1, i - 1) .. (chop and "" or c)
      self.bufferRead = buf:sub(i + #c)
      return result
    else
      start = #self.bufferRead - (is_cr and 1 or 0)
      local result, reason = readChunk(self)
      if not result then
        if reason then
          return nil, reason
        else -- eof
          result = #self.bufferRead > 0 and self.bufferRead or nil
          self.bufferRead = ""
          return result
        end
      end
    end
  end
end

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всегда считал, что переменные(они же указатели на объекты) не могут занимать много памяти... Хотя бы потому что исходники библиотек OpenOS прямо-таки напичканы переменными. Может дело все-таки не в таких мелочных деталях как переменные, а в самой реализации?

 

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

 

А насчет исходников OpenOS - с каких это пор они стали эталоном грамотного и эффективного кода? Лично я вообще не понимаю, что в ней может кушать столько памяти (пс-с-ст, более 200 КБайт по дефолту, жуть какая). Хотя приведенный тобой пример вносит определенную ясность хд

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Реализована возможность запуска нескольких программ одновременно!!!
В этом примере каждая программа запущена в отдельном окне 10х10 символов.
agigi.gif


Это 2 одинаковых программы. Эта программа будучи запущенной в "одиночном" режиме занимает все окно:
agigi.png


Примечание: в скиншоты попал мой терминал(фиолетовая область). Я криворукий и мне лень переделывать

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

Изменено пользователем RccHD
  • Like 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем RccHD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Приведи пример такой коллизии. Я пока не придумал ни одного

Изменено пользователем RccHD

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот еще интересный, красочный пример. Запустил две змейки на одном компе:

vokoscreen-2017-09-02_06-15-30.gif

Проблема только в том, что обе змейки реагируют на нажатия клавиш, но эта проблема легко решаемая :)

P.S. Программу "змейка" я скачал с форума и запустил в своей ОС без каких-либо доработок

Изменено пользователем RccHD
  • Like 3

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Увы, такой подход крайне нерационален. Безусловно, визуально куда проще выделить локальную переменную под жирную таблицу с множеством вложенных обращений, сэкономив тем самым несколько тиков - однако если бы я использовал такой подход при написании требовательного софта, то он вылетал бы с not enough memory еще до старта. Примером может послужить наш 3D-движок: сборщик мусора банально не успевал очищать локальные переменные-указатели на таблицы векторов при отрисовке сцен, и ошибка о нехватке памяти вылезала как результат. Сократив подобный "некорявый код" до минимума, мы смогли запустить движок всего лишь на 2 МБ RAM. Так что лучше помучиться с лишними буковками, нежели писать неоптимизированное в данном контексте ПО. Имхо, конечно же

RccHD немного не убедительно написал, я попробую его поправить.

  1. выполнение buffer.currentFrame[index]

     -- обращение к переменной buffer

     -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ.

         - расчёт hash("currentFrame")

         - определение смещения по хешу

         - выборка списка (может дерева) элементов по смещению из массива

         - разрешение коллизий (дорого)

         - ...

     -- выборка из полученной таблицы элемента с индексом, что приводит к 'см выше'

     -- если вы 'lucky boss' то разрешение кеш промахов (это очень затратная операция)

  2.  выборка значения переменной

     -- если интерпретатор lua переменную положил на стек, то это бесплатная операция, иначе:

         - чтение данных из ОЗУ (если есть кеш, то это тоже почти бесплатная op)

         - в худшем случае разрешение 1 кеш промаха

Мне что-то подсказывает, что выполнять операцию (1) много раз не стоит.

Если у вас есть проблемы со своевременной очисткой памяти, то можно вручную вызвать сборку мусора.

Но таких проблем быть не должно.

Мне кажется, что кто-то просто забывает писать ключевое слово local.

И переменная весит ровно 64 бита.

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

то можно написать var = nil. И gc, по возможности, удалит объект, на который ссылалась переменная.

А сама ссылка удалится как закончится её область видимости (без gc).

Изменено пользователем Seryoga

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

RccHD немного не убедительно написал, я попробую его поправить.

  1. выполнение buffer.currentFrame[index]

     -- обращение к переменной buffer

     -- обращение к полю объекта. Но мы имеем дело с lua, по-этому buffer это HashMap а currentFrame это ключ.

         - расчёт hash("currentFrame")

         - определение смещения по хешу

         - выборка списка (может дерева) элементов по смещению из массива

         - разрешение коллизий (дорого)

         - ...

 

Спасибо за пояснение очевидного. Ты забываешь про буфер хешмапы, ускоряющий поиск часто используемых объектов - в большинстве случаев описанные тобой операции банально "скипаются", особенно в нашем контексте, где используется обращение к одним и тем же вложенным таблицам.

 

Если у вас есть проблемы со своевременной очисткой памяти, то можно вручную вызвать сборку мусора.

 

Ручной вызов GC в OpenComputers невозможен, эта фича отключена авторами мода по понятным причинам. Если бы я мог активировать сборку мусора - то неужели стал бы писать сюда о проблемах с локальными переменными?

 

И переменная весит ровно 64 бита.

 

Переменная весит столько, сколько определено ее типом: строки занимают 17 байт + длина самой строки, таблица кушает 40 байт + ее содержимое, каждая функция - 20 байт + локальные данные. Пожалуйста, не пиши глупости без знания матчасти.

 

Мне кажется, что кто-то просто забывает писать ключевое слово local.

 

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

  • Like 2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Переменная весит столько, сколько определено ее типом: строки занимают 17 байт + длина самой строки, таблица кушает 40 байт + ее содержимое, каждая функция - 20 байт + локальные данные. Пожалуйста, не пиши глупости без знания матчасти.

Переменная весит сколько весит ссылка в ОS.

А вот объект на который ссылается переменная весит в зависимости от типа.

Как ты понимаешь ссылка это не объект на стеке и она ссылается на объект в твоей мапе который ты и так хранишь.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за пояснение очевидного. Ты забываешь про буфер хешмапы, ускоряющий поиск часто используемых объектов - в большинстве случаев описанные тобой операции банально "скипаются", особенно в нашем контексте, где используется обращение к одним и тем же вложенным таблицам.

Даже если это так, то ты наверное понимаешь, что это всё равно не сравнимо с чтением объекта по ссылке.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Переменная весит сколько весит ссылка в ОS.

А вот объект на который ссылается переменная весит в зависимости от типа.

Как ты понимаешь ссылка это не объект на стеке и она ссылается на объект в твоей мапе который ты и так хранишь.

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

 

Для справки: каждая переменная-указатель на таблицу или функцию в Lua весит в равной мере 9 байт.

 

А теперь немного сухих расчетов: представим простейшую трехмерную сцену из восьми кубиков. Каждый куб имеет 8 вершин, каждая вершина - это трехмерная таблица-вектор с числовой индексацией, в сумме кушающая 40 (table) + 8 (double) * 3 = 64 байта. Все вершины заносятся в массив вершин сцены для минимизации расхода памяти. Также каждый куб имеет таблицу-линковщик, содержащую индексы вершин, образующие треугольники для отрисовки куба в количестве 12 штук. Каждый треугольник с ссылками на три вершины - это такой же трехмерный вектор, кушающий все так же 64 байта. Итого получаем 64 * 8 = 512 байт на вершины и 64 * 12 = 768 байт на линковку вершин, итого 1280 байт на куб. Сколько у нас там их? Восемь? Итого трехмерная сцена выжрет 1280 * 8 = 10240 байт = 10 КБайт. Это тот минимум, который необходим для старта отрисовки графики, материалы и текстуры для простоты рассматривать не будем. Если же использовать локальные переменные-сокращалки, то расход памяти взлетит по экспоненте.

 

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

for triangleIndex = 1, #OCGL.triangles do
	vertex1[1], vertex1[2], vertex1[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][1]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][1]][2], OCGL.vertices[OCGL.triangles[triangleIndex][1]][3]
	vertex2[1], vertex2[2], vertex2[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][2]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][2]][2], OCGL.vertices[OCGL.triangles[triangleIndex][2]][3]
	vertex3[1], vertex3[2], vertex3[3] = renderer.viewport.xCenter + OCGL.vertices[OCGL.triangles[triangleIndex][3]][1], renderer.viewport.yCenter - OCGL.vertices[OCGL.triangles[triangleIndex][3]][2], OCGL.vertices[OCGL.triangles[triangleIndex][3]][3]
	material = OCGL.triangles[triangleIndex][4]

...

Также привожу скриншот с результирующим FPS в 7 единиц и расходом оперативной памяти в 46% от максимального запаса (4 Мб)

 

IXkJ4qZ.png?1

 

 

А теперь намутим-ка локальных сокращений для минимизации нагрузки на ЦП:

local ti, ve1, ve2, ve3
for triangleIndex = 1, #OCGL.triangles do
	
	ti = OCGL.triangles[triangleIndex]
	ve1, ve2, ve3 = OCGL.vertices[ti[1]], OCGL.vertices[ti[2]], OCGL.vertices[ti[3]]

	vertex1[1], vertex1[2], vertex1[3] = renderer.viewport.xCenter + ve1[1], renderer.viewport.yCenter - ve1[2], ve1[3]
	vertex2[1], vertex2[2], vertex2[3] = renderer.viewport.xCenter + ve2[1], renderer.viewport.yCenter - ve2[2], ve2[3]
	vertex3[1], vertex3[2], vertex3[3] = renderer.viewport.xCenter + ve3[1], renderer.viewport.yCenter - ve3[2], ve3[3]
	material = OCGL.triangles[triangleIndex][4]

...

Результат плачевный. Не замечено ни прироста, ни убыли значений FPS, однако расход памяти возрос до 61%. Магия? Нет, особенности конкретного ЯП и его интеграции в виде мода.

 

tq3OUxU.png?1

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

  • Like 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Словом «все», взятым в кавычки, я надеялся выразить свою иронию. Но твоя новая формулировка меня устраивает: большинство программ – это не все программы, тем более с таким выделением жирным шрифтом:

Важно: все OpenOS-программы можно будет запустить на моей OC

Многозадачность можно реализовать двумя путями:

 

1) Подменить load своей функцией, автоматически расставляющей по всему коду вызовы yielding. Недостатки этого способа в том, что он провоцирует повышенное потребление памяти и процессорного времени, и годится не для любого кода. Достоинство в том, что потенциально он может спасти систему от падения в TLWY из-за одного кривого приложения.

 

2) Подменить буквально все методы всех компонент, которые неявно выполняют уступку времени. Начать, конечно, следует с computer.pullsignal, но этого недостаточно. Например, есть программы, которые не выполняют sleep/listen, а длительно работать без TLWY им позволяют обращения к периферии. Если ты готов подменить методы всех компонент, добавляя в каждый из них вызов yielding – пожимаю руку. Еще надо не забыть, что периферия может динамически подключаться и отключаться от компьютера, и таблицы методов нужно будет подменять на лету.

 

Предполагаю, что ты выбрал второй способ, удовлетворившись подменой pullsignal, да gpu

 

Приведи пример такой коллизии. Я пока не придумал ни одного

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Многозадачность можно реализовать двумя путями:

 

Есть третий принципиально отличающийся вариант: обработка нескольких приложений-окон в общем потоке-контейнере. Из плюсов тут стоит выделить максимальное быстродействие, т.к. выполнение скрипта не будет искусственно замедлено множественными yield() в подмененных функциях, а также простоту написания такого концепта. Из минусов - поддерживать многозадачность будет лишь то ПО, которое написано под данную ОС, все остальное будет работать в штатном режиме. А также имеет место быть стабильный краш главного потока при краше любого из приложений - проблема решается изоляцией пространства приложения от контейнера и кешированием его состояния.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

Есть третий принципиально отличающийся вариант: обработка нескольких приложений-окон в общем потоке-контейнере

Есть пример рабочей реализации? Чтобы две-три программы работали, рисовали графику. Я бы посмотрел исходники  :D  

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Есть пример рабочей реализации? Чтобы две-три программы работали, рисовали графику. Я бы посмотрел исходники

 

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

 

hTFGCqj.gif

Изменено пользователем ECS
  • Like 4

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

 

есть программы, которые не выполняют sleep/listen, а длительно работать без TLWY им позволяют обращения к периф

Это что за программы? Есть пример? Я привык, что всегда нужно pullSignal писать в программе, чтобы она работала 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это что за программы? Есть пример? Я привык, что всегда нужно pullSignal писать в программе, чтобы она работала 

local redstone = require("component").redstone
while true do
  redstone.setOutput(1, math.random(15))
end 

Что примечательно, эту софтину возможно завершить только путем отсоединения редстоун-компонента. Как верно подметил eu_tomat, каждое обращение к нему ведет себя аналогично .pullSignal(), однако не вызывает его

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот еще интересный, красочный пример. Запустил две змейки на одном компе:

 

vokoscreen-2017-09-02_06-15-30.gif

 

Проблема только в том, что обе змейки реагируют на нажатия клавиш, но эта проблема легко решаемая :)

 

P.S. Программу "змейка" я скачал с форума и запустил в своей ОС без каких-либо доработок

Кто-то ещё помнит про мои змейки

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кто-то ещё помнит про мои змейки

Эти змейки почти идеально подходят для тестирования моего оконного менеджера.

Так как в них использованы самые разные функции (gpu, term, event)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.

×