Тут нада чота умное напейсать! Шоб сказал, как отрезал! Но чота ничо не приходит вголову, сцуко (( :D
Из книжки про Операционные Системы Таненбаума и Боса, 4-е изд.
читать дальшеЕщё забыл сказать, шо это - где-то в памяти ядра хранится таблица открытых файлов, в которой записаны все открытые в данный момент файлы и позиция их внутреннего указателя. Процесс-родитель видит, какие файлы открыты дочерним процессом, а вот наоборот видит ли дочерний процесс родительские файлы - не знаю. Возможно, тоже видит. Ваще - открытые до того, как он родился - стопудово видит - их дескрипторы копируются в его структуру, и щитаецца, что он их какбэ тоже открыл, а вот если родительский после рождения чо откроет, вот это хз.
Если родительский процесс пейсал что-то в стандартный вывод (например, перенаправленный в файл), потом вызвал дочерний, он тоже пишет в этот же вывод с места, где закончил родительский, т.к. при вызове fork он унаследовал дескрипторы открытых файлов, а в ядре хранилось смещение в этих файлах. Дочерний процесс выходит, а смещение остаётся там, где он закончил пейсать. Родительский опять пишет, потом вызывает второй дочерний и так далее. В файле их вывод не затрёт друг друга, а будет идти последовательно. Пиздец, да? Вот же ж придумали!
Это что ж получается? Если родительский процесс открыл файл, а потом назапускал до хера потоков, они все могут последовательно пейсать в общий файл? Получается так. А по-другому у них и не получится пейсать, да? Токо последовательно. Но ведь, чтобы пейсать, нужна эксклюзивная блокировка файла, не? Один ставит лок и может пейсать, другие в этот момент могут токо читать. Не, не нужна. Во, я забурился тут wm-help.net/lib/b/book/2075737573/331 Блокировку можно поставить на диапазон, причём, относительно текущей позиции смещения SEEK_CUR или относительно конца файла SEEK_END. Что такое SEEK_SET, даже они умалчивают - никто не хочет говорить всего, такой он сцуко Линукс, сплошная недосказанность. И есть поле l_len - сколько блокировать в байтах. Но если мы поставим SEEK_END, зададим длину, а потом начнём пейсать в конец, SEEK_END же будет сдвигацца?
или тут имеется ввиду SEEK_END, как он был на момент объявления блокировки? Типа, мы относительно него объявили и дальше файл начал расти. Надеюсь, что так.
Можно накладывать блокировки на конкретный диапазон байтов файла. Блокировка может быть с монополизацией (exclusive locks) - видимо, чтение-запись и блокировка без монополизации (shared locks), только чтение.
Пиздец, как я заебался читать, а просветление всё не наступает.
Про Андроид. Андроид это ядро Линукс с несколькими расширениями. Например, блокировка сна. Все процессы Андроида дрочат на блокировку сна, передают эстафету друг другу - если один её убирает, дабы передать управление другому процессу, другой тут же выставляет, иначе устройство заснёт и пиздец.
Контроль памяти. Т.к. раздела подкачки там нет, Андроид гораздо жоще контролирует память, и если её остаётся мало, бежалосно килит приложения. У каждого процесса есть параметр oom_adj, в котором указаны его запросы к памяти, и Андроид килит сначала самые жирные процессы, потом помельче.
Приложения написаны на Яве, некоторые вставки есть на С++. Через это нужна среда выполнения Ява. Там она называется Dalvik и её байт-код отличается от обычного большей компактностью. Типа, обычная Ява это стек-ориентированная машина, а Dalvik регистроориентированная. Сначала приложение пишецца на обычной Яве, компилится в байт-код, а потом этот байт-код перекомпиливается в байт-код Dalvik. Каждое приложение запускается в своём собственном процессе Линукс со своей собственной средой выполнения Dalvik. Чтобы это происходило быстро, в системе выполняется демон zygote - копия пустой среды Dalvik. Когда надо запустить приложение, zygote форкается, и в его копию загружается приложение.
Межпроцессных каналов в стандартном понимании в Андроиде нет, вместо них используется RPC релизованное в виде модуля ядра Binder.
В ядре для каждого процесса имеется область памяти, которую видит и ядро и процесс - для обмена информацией с другими процессами. Ядро само создаёт в этих областях ссылки на объекты других процессов и предоставляет процессу дескрипторы этих объектов.
Про приложения Андроид - это ваще откровение. Приложение там упаковано в контейнер со всем необходимым. И оно имеет не одну точку входа, а несколько. И фрагменты приложения стандартизированы, а их тырфейс описан на AIDL - Android Interface Definition Language. Фрагменты приложения могут быть нескольких типов и действуют независимо друг от друга. Точнее, они действуют не то, чтобы сами - их вызывает система. Типы следующие:
Активность - это собсно приложение, Активностей может быть несколько - например, главное окно, это одна, а окно чата - другая, и они независимы друг от друга. Глупый юзер думает, что находится в одной программе, а если я всё правильно понял, переход из чатика в окно контактов вотсапа - это переход из одной программы в другую, но в рамках одного контейнера приложения.
Служба - это то, что висит в фоне и отслеживает сообщения. То есть, согласно этой концепции - ярлык вотсапа на экране, это служба, а главное окно вотсапа - это Активность.
Получатель - это такой одноразовый триггер, которая ждёт определённого события. Когда событие случается, получатель то ли сообщает, то ли запускает чо-то и удаляется.
Поставщик Контента - тут, как я понял, публикуются ссылки на объекты приложения, по которым другие приложения могут открыть в своём окне фрагмент текущего приложения. Или необязательно окне, вот, например, когда в вотсап надо послать снимок, видимо, вотсап обращается к поставщику контента камеры или Галереи и открывает внутри себя окно этой Галереи.
Намерение. Бывают явные и неявные. Это не фрагмент программы, а список того, что одно приложение собирается пытацца делать с помощью других приложений. Звучит сложно. В общем, ты ставишь приложение, и оно сообщает системе "Я буду посылать, я буду делицца, я буду фоткать - соотвецтвенно мне нужны приложения, которые могут это делать" Явные намерения это прям конкретно сцылка на объекты другого приложения. Это приложение должно уже быть, а если его нет, наверное система должна об этом сказать или предложить установить, хз. Неявное интереснее - это название действия. Другие приложения (в Активностях) сообщают системе, что они могут делать. Например, посылать у нас может вотсап, вайбер, делицца они же + Инстаграмм и всякие соцсети. Когда приложение выражает неявное намерение что-то сделать, система с помощью компонента ResolverActivity запрашивает все имеющиеся приложения - кто из вас может это сделать? Если никто, клиент посылается нахуй, если одно, то его окно открывается на экране, если несколько, появляется диалог выбора и решить должен юзер.
Короче, меня тут поразило то шо глупый юзер думает, что работает в рамках одной программы и она каким-то чудесным образом знает, какие у него установлены приложения и какие из них могут выполнить именно то, что нужно. На самом деле программы сменяют друг друга - одно приложение - система - другое приложение.
Ещё оказывается, проги ставятся с разным uid, чтобы не лазили друг к другу. Две копии одной проги тоже будут иметь разные uid.
Андроид имеет процесс system_server, внутри которого может сохранять состояния других процессов. Потом он может килить эти процессы в случае нехватки памяти, а когда нехватка прошла, восстанавливать покиленные процессы с помощью сохранённого состояния процесса.
читать дальшеЕщё забыл сказать, шо это - где-то в памяти ядра хранится таблица открытых файлов, в которой записаны все открытые в данный момент файлы и позиция их внутреннего указателя. Процесс-родитель видит, какие файлы открыты дочерним процессом, а вот наоборот видит ли дочерний процесс родительские файлы - не знаю. Возможно, тоже видит. Ваще - открытые до того, как он родился - стопудово видит - их дескрипторы копируются в его структуру, и щитаецца, что он их какбэ тоже открыл, а вот если родительский после рождения чо откроет, вот это хз.
Если родительский процесс пейсал что-то в стандартный вывод (например, перенаправленный в файл), потом вызвал дочерний, он тоже пишет в этот же вывод с места, где закончил родительский, т.к. при вызове fork он унаследовал дескрипторы открытых файлов, а в ядре хранилось смещение в этих файлах. Дочерний процесс выходит, а смещение остаётся там, где он закончил пейсать. Родительский опять пишет, потом вызывает второй дочерний и так далее. В файле их вывод не затрёт друг друга, а будет идти последовательно. Пиздец, да? Вот же ж придумали!
Это что ж получается? Если родительский процесс открыл файл, а потом назапускал до хера потоков, они все могут последовательно пейсать в общий файл? Получается так. А по-другому у них и не получится пейсать, да? Токо последовательно. Но ведь, чтобы пейсать, нужна эксклюзивная блокировка файла, не? Один ставит лок и может пейсать, другие в этот момент могут токо читать. Не, не нужна. Во, я забурился тут wm-help.net/lib/b/book/2075737573/331 Блокировку можно поставить на диапазон, причём, относительно текущей позиции смещения SEEK_CUR или относительно конца файла SEEK_END. Что такое SEEK_SET, даже они умалчивают - никто не хочет говорить всего, такой он сцуко Линукс, сплошная недосказанность. И есть поле l_len - сколько блокировать в байтах. Но если мы поставим SEEK_END, зададим длину, а потом начнём пейсать в конец, SEEK_END же будет сдвигацца?
или тут имеется ввиду SEEK_END, как он был на момент объявления блокировки? Типа, мы относительно него объявили и дальше файл начал расти. Надеюсь, что так.Можно накладывать блокировки на конкретный диапазон байтов файла. Блокировка может быть с монополизацией (exclusive locks) - видимо, чтение-запись и блокировка без монополизации (shared locks), только чтение.
Пиздец, как я заебался читать, а просветление всё не наступает.
Про Андроид. Андроид это ядро Линукс с несколькими расширениями. Например, блокировка сна. Все процессы Андроида дрочат на блокировку сна, передают эстафету друг другу - если один её убирает, дабы передать управление другому процессу, другой тут же выставляет, иначе устройство заснёт и пиздец.
Контроль памяти. Т.к. раздела подкачки там нет, Андроид гораздо жоще контролирует память, и если её остаётся мало, бежалосно килит приложения. У каждого процесса есть параметр oom_adj, в котором указаны его запросы к памяти, и Андроид килит сначала самые жирные процессы, потом помельче.
Приложения написаны на Яве, некоторые вставки есть на С++. Через это нужна среда выполнения Ява. Там она называется Dalvik и её байт-код отличается от обычного большей компактностью. Типа, обычная Ява это стек-ориентированная машина, а Dalvik регистроориентированная. Сначала приложение пишецца на обычной Яве, компилится в байт-код, а потом этот байт-код перекомпиливается в байт-код Dalvik. Каждое приложение запускается в своём собственном процессе Линукс со своей собственной средой выполнения Dalvik. Чтобы это происходило быстро, в системе выполняется демон zygote - копия пустой среды Dalvik. Когда надо запустить приложение, zygote форкается, и в его копию загружается приложение.
Межпроцессных каналов в стандартном понимании в Андроиде нет, вместо них используется RPC релизованное в виде модуля ядра Binder.
В ядре для каждого процесса имеется область памяти, которую видит и ядро и процесс - для обмена информацией с другими процессами. Ядро само создаёт в этих областях ссылки на объекты других процессов и предоставляет процессу дескрипторы этих объектов.
Про приложения Андроид - это ваще откровение. Приложение там упаковано в контейнер со всем необходимым. И оно имеет не одну точку входа, а несколько. И фрагменты приложения стандартизированы, а их тырфейс описан на AIDL - Android Interface Definition Language. Фрагменты приложения могут быть нескольких типов и действуют независимо друг от друга. Точнее, они действуют не то, чтобы сами - их вызывает система. Типы следующие:
Активность - это собсно приложение, Активностей может быть несколько - например, главное окно, это одна, а окно чата - другая, и они независимы друг от друга. Глупый юзер думает, что находится в одной программе, а если я всё правильно понял, переход из чатика в окно контактов вотсапа - это переход из одной программы в другую, но в рамках одного контейнера приложения.
Служба - это то, что висит в фоне и отслеживает сообщения. То есть, согласно этой концепции - ярлык вотсапа на экране, это служба, а главное окно вотсапа - это Активность.
Получатель - это такой одноразовый триггер, которая ждёт определённого события. Когда событие случается, получатель то ли сообщает, то ли запускает чо-то и удаляется.
Поставщик Контента - тут, как я понял, публикуются ссылки на объекты приложения, по которым другие приложения могут открыть в своём окне фрагмент текущего приложения. Или необязательно окне, вот, например, когда в вотсап надо послать снимок, видимо, вотсап обращается к поставщику контента камеры или Галереи и открывает внутри себя окно этой Галереи.
Намерение. Бывают явные и неявные. Это не фрагмент программы, а список того, что одно приложение собирается пытацца делать с помощью других приложений. Звучит сложно. В общем, ты ставишь приложение, и оно сообщает системе "Я буду посылать, я буду делицца, я буду фоткать - соотвецтвенно мне нужны приложения, которые могут это делать" Явные намерения это прям конкретно сцылка на объекты другого приложения. Это приложение должно уже быть, а если его нет, наверное система должна об этом сказать или предложить установить, хз. Неявное интереснее - это название действия. Другие приложения (в Активностях) сообщают системе, что они могут делать. Например, посылать у нас может вотсап, вайбер, делицца они же + Инстаграмм и всякие соцсети. Когда приложение выражает неявное намерение что-то сделать, система с помощью компонента ResolverActivity запрашивает все имеющиеся приложения - кто из вас может это сделать? Если никто, клиент посылается нахуй, если одно, то его окно открывается на экране, если несколько, появляется диалог выбора и решить должен юзер.
Короче, меня тут поразило то шо глупый юзер думает, что работает в рамках одной программы и она каким-то чудесным образом знает, какие у него установлены приложения и какие из них могут выполнить именно то, что нужно. На самом деле программы сменяют друг друга - одно приложение - система - другое приложение.
Ещё оказывается, проги ставятся с разным uid, чтобы не лазили друг к другу. Две копии одной проги тоже будут иметь разные uid.
Андроид имеет процесс system_server, внутри которого может сохранять состояния других процессов. Потом он может килить эти процессы в случае нехватки памяти, а когда нехватка прошла, восстанавливать покиленные процессы с помощью сохранённого состояния процесса.
@темы: Linux
