Продажи девайсов не показатель. Можно купить - поиграться - и положить на полку! Именно софт тут тот маркер - что говорит о популярности - нет софта - нет популярности - конечно тут сильная взаимосвязь - но как только станет много софта - вот тогда точно можно будет говорить о популярности! А пока там проблем слишком много. А высокие продажи - это скорее лишь заслуга маркетологов!
А насчёт цена/качество - я бы не был таким позитивным - по десятибалльной шкале это соотношение на 2 бала - и вот только только недавно перевалило выше единицы - да и то, только на самых топовых моделях. У ширпотреба до единицы даже ещё далековато...
Но кому то и так нравится!
А сейчас надо ждать пока эппл выполнит работу над ошибками со своим вижен про. А это как минимум ещё 2 поколения, а то и 3 (это ещё лет 6, не включая 2024 год). Если вообще выполнит. У эппла дела хорошо шли с новыми продуктами только при Джобсе...
И только потом, в случае успешной работе над ошибками, и другие производители начнут подтягиваться (это ещё лет 6) - вот тогда и, возможно, сильная конкуренция сдвинет всё с мёртвой точки. Но я склонен на это смотреть негативно - и побарахтавшись лет 10 - всё это VR/AR снова канет в небытие (в узкую нишу потребления) - не время ещё...
Тем более - мобильное - тут со стационарным то проблем вагон и малая тележка, а уж с мобильными технологиями...
Ну почему же - не яблочные смартфоны продаются же очень хорошо.. и среди их владельцев есть доля тех, что перешёл на них именно с яблока (хоть и говорят, что такая миграция - редкость, а в основном те, кто не пользуется яблофонами - просто не могут их себе позволить - но, на мой взгляд, это яблочная пропаганда хотя у меня есть знакомые, кто с яблока переходил на гнусмас - обплевался и вернулся на яблоко - но это ещё до эпохи гибких экранов было; лично я пользовал яблоко - это был мой самый негативный опыт в использовании электроники - больше я к ним ни ногой)!
Бесспорно за VR и AR будущее. Но доросли ли мы уже до его начала?.. думаю пока ещё нет. Тема VR барахтается уже лет 50... а реальных серьёзных подвижек нет до сих пор. Ничего принципиально нового за последние лет 30 не предложили... ну разве что ковёр от Дисней (!) может оказаться интересным - но пока не поступит в продажу тут говорить ещё не о чем.
Технических проблем у технологий виртуальной визуализации просто куча. Биофизических проблем не меньше. Экономических проблем выше круши.
Но тренд, где-то уже в третий раз начатый около 10 лет назад - пока не утихает - бизнес готов вкладываться в это, в надежде, что вот вот эта сфера "выстрелит". Но, лично я, в это не верю, пока не верю.
Безусловно - инвестиции последних 10 лет позволили данным технологиям восстать из забвения, со времён второго прихода, произошедшего около 30 лет назад; но с тех пор в массы так ничего и не вышло! Но да - для гиков поиграться и для некоторых серьёзных бизнес-клиентов или военных технология уже пригодна - но пока это всё слишком нишевой продукт. И вряд ли ситуация изменится в ближайшие десятилетия... скорее всего придётся как минимум подождать ещё лет 30 - четвёртый приход! А то и до пятого ждать придётся - уже ближе к концу века. А там, уже может и до нейролинка с 3D визуализацией рукой подать - и... добро пожаловать в Матрицу или в 2035: Город-призрак
Хочу предложить и другой способ восстановления работоспособности при нехватке памяти – для случая многопоточных приложений. В общем случае это модель не только для решения кризисной ситуации нехватки памяти, но в частности я буду описывать только данную кризисную ситуацию.
Наряду с обычными рабочими потоками заранее создаём поток восстановления – который в обычном режиме может периодически проверять общий объём свободной памяти и на основе этого значения применять какие-то превентивные меры. Но обсуждать далее буду только уже состояние кризиса. В этом случае код, попытавшийся выделить память, и столкнувшийся с её нехваткой (не буду тут акцентировать момент на то, каким образом это зафиксировано, например, это функция malloc вернула нулевой указатель) выставляет общий флаг (условно) для выставления пометки кризисного режима нехватки памяти. Вот его и отслеживает данный поток – после чего начинает процесс восстановления доступности памяти. Но тут есть ряд важных деталей, о которых ниже.
Во-первых. Предлагаю сразу разделить все операции выделения памяти на несколько приоритетов, задаваемых явно при выделении памяти:
1. Пофиг – Алгоритму пофиг на данное выделение памяти, он либо напрямую его не использует, либо готов к тому память не будет выделена и это не повлияет существенным образом на его работу. Например, это может быть выделение под кэш, или какие-то вспомогательные данные, не влияющие на основную работу
2. Не важно – Алгоритму нужно это выделение памяти, но не важно – если память выделить не удастся – алгоритм сможет грамотно это обработать – например подождать, или попробовать выделить память поменьше, или просто завершить какой-то параллельный процесс неудачей – а его данные буду обработаны другим процессом (потоком – но это не принципиально как технически это реализовано)
3. Важно – Алгоритму нужно это выделение памяти, но он готов к проблемной ситуации – либо как-то обработает, либо, «условно упадёт» - перейдя в режим восстановления работы
4. Критично – Алгоритму критически нужно данное выделение памяти, он «до последнего» будет надеяться, что память ему всё-таки дадут
5. Обязательно – Алгоритм остро нуждается в выделении памяти – любой отказ смерти подобен – нужно изыскать её по что бы то ни стало – жертвую всем чем можно (вообще, в обычной работе не должно быть таких запросов на выделение памяти)
6. Резервное – Алгоритм запрашивает резервную память – это уже из области режима восстановления (про резервную память писал ранее – память, которая отдельно заранее зарезервирована)
7. Восстановление – Этот запрос на выделение памяти идёт из алгоритма восстановления –выделяется в отдельный приоритет, чтобы не уйти в рекурсию
8. Системно – Прочие системные выделения памяти с наивысшим приоритетом – невозможность выделения чревата крахом всей системы
Первые три приоритета при нехватке памяти просто не будут её получать. Но третий режим готов немного подождать, включив глобальный маркер.
Четвёртый приоритет будет ждать пока не будет выставлен другой глобальный маркер – информирующий о том, что с выделением памяти действительно большая проблема и простыми путями её не получить – грубо говоря, без жертв не обойдётся. Это значит, что и резервная память уже исчерпана. Текущий алгоритм скорее всего будет «падать» (в исключение или как-то иначе прерывать свою работу).
Пятый приоритет – тоже самое, что и четвёртый – но выставляет маркер требования жертв – тут могут быть завершены другие потоки (НЕ НАХОДЯЩИЕСЯ В КРИТИЧЕСКИХ СЕКЦИЯХ) – коли памяти так и не будет.
Шестой, седьмой – это специальный режим выделения памяти из алгоритмов восстановления памяти. Не начинают других процессов и нечего не ожидают.
Восьмой приоритет – то же самое, что и четвёртый – но требует немедленного выделения памяти – если никаких резервов нет – то он алгоритм «упадёт», и скорее всего потянет за собой весь процесс.
Соответственно далее обработка выделения памяти может вести себя несколько по-разному – для разных приоритетов выделения памяти. Но главное – она будет выставлять разные глобальные маркеры критичности ситуации.
Во-вторых. У нас есть отдельный поток восстановления. Он анализирует выставленные маркеры и принимает различные меры восстановления:
1. Чистит кэш
2. Сокращает буферы
3. Удаляет временные и вспомогательные объекты (которые были таковыми заранее зарегистрированы)
4. Выгружает какие-то данные, условно, на диск
5. Выполняет какую-то упаковку больших данных
6. Насильно (или поначалу мягко) завершает выполнение каких-то процессов (потоков)
Всё это делается очень аккуратно, с некоторой расстановкой приоритетов, с постоянным контролем свободной памяти.
В-третьих. Все алгоритмы восстановления стараются не выделять память на куче – но если нужно – то делать это с контролем и в режимах: Резервно, Восстановление, Системно – но чаще именно в режиме Восстановление, т.е. остальные режимы слишком специфические
В-четвёртых. Когда памяти становится достаточно - то делается некоторая задержка, в потоке восстановления, чтобы стартовали все приостановленные потоки, после чего память снова проверяется – и если её по-прежнему достаточно – снимаются кризисные маркеры и поток временно засыпает до следующей автопроверки.
В-пятых. Если восстановление так и выходит на необходимый объём памяти – выставляется маркёр отказа в обслуживании – все запросы памяти получают отказ – и алгоритмы, как и потоки сворачиваются – приложение устремляется к некоторой базисной точке – происходит глобальная чистка памяти – далее приложение перезапускает свою работу – но если памяти по-прежнему не хватает – приложение окончательно «падает»
Приобретение богатства — больше не та сила, которая движет нашими жизнями. Мы работаем, чтобы улучшить себя и человечество» — цитата капитана Жан-Люка Пикара из сериала «Звёздный путь: Следующее поколение
Я бы не стал связывать сей лозунг с идеями коммунизма или социализма. Но мой взгляд - самый что ни на есть тоталитарный (возможно тоталитарно демократический - если таковым считать нынешний демократический курс прогрессивного запада) лозунг. Где слова - лишь ширма, за которой скрывается многослойное общество, либо увязшее во взаимном контроле, либо жёстко насильно подчинённое высшей власти; где лишь верхушка этого улия может хоть как-то чувствовать себя свободными - но и это скорее всего утопия - там тоже царствуют законы взаимосдерживания, просто сдерживают там лишь необъятные амбиции, а не повседневные потребности!
Все, кто ниже - неявно угнетаются и подчиняются общим законам и устремлениям, диктуемым сверху. Если кто-то ещё в состоянии быть против - он отвергается (искореняется системой) - и существует вне её! Так что это не утопия - это скорее антиутопия! Пример - вот фильм Разрушитель, например. Или сериал Экспансия - где очень тонко было показано всё натяжение между разными слоями общества (и речь даже не про астеров, на той же Земле всё очень даже не гладко). Ещё одна такая утопия (где, правда будущее показано лишь вскользь - зато очень в опасном ключе за розовой ширмой) - это сериал Континуум. Просто в Звёздном пути в это решили не углубляться - сказка для детей же, а не политический триллер для взрослых!
А такой лозунг из "Звёздного пути" очень явно намекает на то - что жизнями простых смертных там явно движет что-то другое.... что даже назвать страшно!
Формально согласен - при восстановлении соединения номер сокета не должен играть ключевую роль - иначе - это архитектурная ошибка. Другое дело - что если удалённая сторона и её архитектура от Вас никак не зависит, и приходится работать с тем что есть
Но - тут сохранить номер сокета вообще не проблема даже при нехватке памяти
Надо перехватить исключение до того как он будет освобождён, только и всего
А вот это не всегда архитектурно удобно! И фактически отменяет более половины всех преимуществ исключений. Это уже другая тема
Я Вам отвечал на Ваше утверждение, что любой объект можно пересоздать объект. И как выкручиваться, когда это сделать невозможно, но нужно обработать исключение где-то выше по стеку
Тут какое-то непонимание ситуации. Что мы вообще обсуждаем?
Я так понял обсуждаем то, что объект может являться ресурсом, который создаётся на время выполнения какого-то кода - после чего финалится и освобождается
Но возникновение исключения не позврляет отрабоать всей секции кода до конца - и объект может быть зафинален и освобождён. Но затем мы делаем восстановление роботоспособности - и нам нужен этот самый объект для продолжения работы.
Выше я рассказал и то, как можно поступать в таких случаях
И то, что не все объекты можно вот так взять и пересоздать!
Безусловно - всё что можно пересоздать - можно и пересоздать! Но, даже, например, при взаимодействии с СУБД - не факт, что новая выборка Вам вернёт те же данные. А Вам нужны исходные - чтобы завершить начатый процесс, который если корректно не завершить со старыми данными - то хрен знает что случится тогда!
То есть, с некоторыми данными действительно надо быть аккуратными и не терять! Даже если формально есть процесс получения новых! Вот только есть ли уверенность на 100% что всё будет стабильно при повторном получении?
что вам мешает точно так же вернуть его назад при исключении?
А вот это я не вообще не понял. Напомню - что тут обсуждение работы в кризисной ситуации - в частности ситуации нехватки памяти!
Дополнил комментарий (хотя и так должно быть понятно), прочитайте ещё раз. Если по-прежнему не понятно почему - я навряд ли до Вас доведу эту мысль
Хотя... ну вот другой пример без кода:
У Вас приложение взаимодействует скажем с онлайн магазином билетов - вы купили билет и потратили на него деньги - получили билет в виде электронного объекта. Утрата объекта = утрата билета. Да - Вы можете получить новый билет из магазина - но Вам снова придётся потратить деньги. Билеты не будут идентичны - и могут даже выполнять одну и ту же функцию, но Вы потратили повторно деньги.
А если это лотерейные билеты - то вопрос выполнения одной и той же функции становится острее - вроде бы одна и та же: функция вероятности получения выигрыша (и эта вероятность от вашего приложения даже не зависит) - вот только это два разных билета - и факт в том, что любой из них в какой-то момент может выиграть - первый или второй! Но первый уже безвозвратно потерян... А за второй Вы и так уже заплатили повторно!
#include <cstdlib>
#include <ctime>
#include <iostream>
class MyObject
{
public: MyObject()
{
init();
}
private: void init()
{
_myData = giveData();
}
private: int giveData()
{
std::srand(std::time(nullptr));
return std::rand();
}
private: int _myData;
public: std::string GetData()
{
return std::to_string(_myData);
}
};
int main()
{
MyObject* o = new MyObject();
std::cout<<"Hello "+o->GetData();
return 0;
}
Идентичный объект выше стабильно пересоздать будет невозможно, чтобы функция GetData() вернула тот же результат
Где функция giveData() условно может быть любой, связанной с неким неконстантным процессом
Но в данном случает такой объект можно выгрузить и загрузить.
но у поля _myData тут простой числовой тип. Но это мог бы быть некий тип, к конструктору которого вообще нет доступа - данные которого создаёт какой-то "чужой" процесс - хотя останется желание выгрузить загрузить его условно побитово - а если там будут ссылки на другие объекты в куче?
Так что с воссозданием объектов всё действительно не так гладко в С++
А насчёт нужности - представьте что этот объект криптоключ, открывающий доступ ко всем рабочим данным. Действующий некоторое время или в течение некоторого процесса, а потом меняющийся - но получение нового требует передачи старого! Область валидности ключа может быть жёстко ограничена областью кода - в котором криптоключ является ресурсом (получается для использования и возвращается назад при завершении работы), но сбой может выкинуть выполнение из области кода использования ключа (при невозможности корректно обработать все процессы обслуживания ключа, в кризисной ситуации) - а возобновление работоспособности приложения потребует сохранение исходного ключа!
Но тут нет технических ограничений в C++ - нужно лишь правильно выстраивать архитектуру владения ключом (ссылки на объект) , в т.ч. при обработке сбоев!
У вас тут спор об особенностях той или иной архитектуры. Он пустой. При любом раскладе всегда можно найти то или иное решение для конкретного случая. А сферическую лошадь в вакууме тут рассматривать бессмысленно!
Но соглашусь с тем что не все объекты всегд можно создать повторно без существенного изменения состояния приложения . Тут просто вопрос иначе надо ставить (для случая кризисной ситуации, в шаге от падения всего приложения):
Что ценнее потерять идентичность какого-то объекта или положить всё приложение?
Можно ли временно выгрузить такой объект (или его важную часть) из памяти, на время восстановления работоспосоности, а потом загрузить её обратно и восстановить идентичность объекта
А правильная ли архитектура работы с такими ценными объектами? Может нужно их держать как-то иначе - чтобы они не терялись в некотором кризисном процессе? В т.ч. вклчив пометку кризисного состояния - не удалять их, при раскрутке стека (хотя тут могут быть организационные сложности при использовании стандартных механизмов отслеживания зоны владения), а сохранять на них ссылку в отдельной области памяти (видимо заранее выделенной), чтобы потом (при, условном, рестарте, не создавать их заново, а взять готовые)
А есть ли ссылки на этот объект (и ссылки внутри объекта) и что с ними делать при его восстановлении?
Сопроводительное письмо всегда было действенным аргументом
Неужели рынок вакансий питониста так перегрет - что откликов на вакансию легко может быть больше 1000? Это по России или по миру?
Наготовили кучу зелёных "специалистов" а работы столько для них нет?
Я всегда предлагал новичкам как первый проф язык учить Java, JavaScript, C# - тут найти вакансию новичку будет проще. С недавних пор тем, кто хочет в мобилки пойти - можно Kotlin порекомендовать (хотя Kotlin это не только мобилки - но это уже темя не для новичков)... но всё же лучше начать с указанной троицы. Swift - на свой страх и риск в России, тоже лучше изучать после ЯП из указанных выше. Как и SQL - кто хочет в СУБД
Python - если преподавали в школе - хорошо - но затем лучше всё-таки изучить ещё один ЯП. Для карьеры в проф-сфере тоже может быть хорошо - но уже для тех, кто с опытом! И опыт тут хорошо набирать применяя этот ЯП как вспомогательный, или переходить на него с другого ЯП, уже в процессе работы над проектами для другого ЯП
Если что - то не смешно. Я то про домашний компьютер спросил
Ждём порт на Baikal-T1
Моя любимая их игра была лишь The Horde ещё под DOS (online) - вот бы ремейк на мобилках ;-)
Хороший перевод хорошей статьи о хорошей серии игр!
А развития нет. Одно барахтанье.
И массы это всё так и не пришло, и придёт не скоро
Для сборки больших проектов Вы бы какой процессор посоветовали? И мамку? И стоит ли гнаться за быстрой памятью?
Продажи девайсов не показатель. Можно купить - поиграться - и положить на полку! Именно софт тут тот маркер - что говорит о популярности - нет софта - нет популярности - конечно тут сильная взаимосвязь - но как только станет много софта - вот тогда точно можно будет говорить о популярности! А пока там проблем слишком много. А высокие продажи - это скорее лишь заслуга маркетологов!
А насчёт цена/качество - я бы не был таким позитивным - по десятибалльной шкале это соотношение на 2 бала - и вот только только недавно перевалило выше единицы - да и то, только на самых топовых моделях. У ширпотреба до единицы даже ещё далековато...
Но кому то и так нравится!
А сейчас надо ждать пока эппл выполнит работу над ошибками со своим вижен про. А это как минимум ещё 2 поколения, а то и 3 (это ещё лет 6, не включая 2024 год). Если вообще выполнит. У эппла дела хорошо шли с новыми продуктами только при Джобсе...
И только потом, в случае успешной работе над ошибками, и другие производители начнут подтягиваться (это ещё лет 6) - вот тогда и, возможно, сильная конкуренция сдвинет всё с мёртвой точки. Но я склонен на это смотреть негативно - и побарахтавшись лет 10 - всё это VR/AR снова канет в небытие (в узкую нишу потребления) - не время ещё...
Тем более - мобильное - тут со стационарным то проблем вагон и малая тележка, а уж с мобильными технологиями...
Ну почему же - не яблочные смартфоны продаются же очень хорошо.. и среди их владельцев есть доля тех, что перешёл на них именно с яблока (хоть и говорят, что такая миграция - редкость, а в основном те, кто не пользуется яблофонами - просто не могут их себе позволить - но, на мой взгляд, это яблочная пропаганда хотя у меня есть знакомые, кто с яблока переходил на гнусмас - обплевался и вернулся на яблоко - но это ещё до эпохи гибких экранов было; лично я пользовал яблоко - это был мой самый негативный опыт в использовании электроники - больше я к ним ни ногой)!
Бесспорно за VR и AR будущее. Но доросли ли мы уже до его начала?.. думаю пока ещё нет. Тема VR барахтается уже лет 50... а реальных серьёзных подвижек нет до сих пор. Ничего принципиально нового за последние лет 30 не предложили... ну разве что ковёр от Дисней (!) может оказаться интересным - но пока не поступит в продажу тут говорить ещё не о чем.
Технических проблем у технологий виртуальной визуализации просто куча. Биофизических проблем не меньше. Экономических проблем выше круши.
Но тренд, где-то уже в третий раз начатый около 10 лет назад - пока не утихает - бизнес готов вкладываться в это, в надежде, что вот вот эта сфера "выстрелит". Но, лично я, в это не верю, пока не верю.
Безусловно - инвестиции последних 10 лет позволили данным технологиям восстать из забвения, со времён второго прихода, произошедшего около 30 лет назад; но с тех пор в массы так ничего и не вышло! Но да - для гиков поиграться и для некоторых серьёзных бизнес-клиентов или военных технология уже пригодна - но пока это всё слишком нишевой продукт. И вряд ли ситуация изменится в ближайшие десятилетия... скорее всего придётся как минимум подождать ещё лет 30 - четвёртый приход! А то и до пятого ждать придётся - уже ближе к концу века. А там, уже может и до нейролинка с 3D визуализацией рукой подать - и... добро пожаловать в Матрицу или в 2035: Город-призрак
Хочу предложить и другой способ восстановления работоспособности при нехватке памяти – для случая многопоточных приложений. В общем случае это модель не только для решения кризисной ситуации нехватки памяти, но в частности я буду описывать только данную кризисную ситуацию.
Наряду с обычными рабочими потоками заранее создаём поток восстановления – который в обычном режиме может периодически проверять общий объём свободной памяти и на основе этого значения применять какие-то превентивные меры. Но обсуждать далее буду только уже состояние кризиса. В этом случае код, попытавшийся выделить память, и столкнувшийся с её нехваткой (не буду тут акцентировать момент на то, каким образом это зафиксировано, например, это функция malloc вернула нулевой указатель) выставляет общий флаг (условно) для выставления пометки кризисного режима нехватки памяти. Вот его и отслеживает данный поток – после чего начинает процесс восстановления доступности памяти. Но тут есть ряд важных деталей, о которых ниже.
Во-первых. Предлагаю сразу разделить все операции выделения памяти на несколько приоритетов, задаваемых явно при выделении памяти:
1. Пофиг – Алгоритму пофиг на данное выделение памяти, он либо напрямую его не использует, либо готов к тому память не будет выделена и это не повлияет существенным образом на его работу. Например, это может быть выделение под кэш, или какие-то вспомогательные данные, не влияющие на основную работу
2. Не важно – Алгоритму нужно это выделение памяти, но не важно – если память выделить не удастся – алгоритм сможет грамотно это обработать – например подождать, или попробовать выделить память поменьше, или просто завершить какой-то параллельный процесс неудачей – а его данные буду обработаны другим процессом (потоком – но это не принципиально как технически это реализовано)
3. Важно – Алгоритму нужно это выделение памяти, но он готов к проблемной ситуации – либо как-то обработает, либо, «условно упадёт» - перейдя в режим восстановления работы
4. Критично – Алгоритму критически нужно данное выделение памяти, он «до последнего» будет надеяться, что память ему всё-таки дадут
5. Обязательно – Алгоритм остро нуждается в выделении памяти – любой отказ смерти подобен – нужно изыскать её по что бы то ни стало – жертвую всем чем можно (вообще, в обычной работе не должно быть таких запросов на выделение памяти)
6. Резервное – Алгоритм запрашивает резервную память – это уже из области режима восстановления (про резервную память писал ранее – память, которая отдельно заранее зарезервирована)
7. Восстановление – Этот запрос на выделение памяти идёт из алгоритма восстановления –выделяется в отдельный приоритет, чтобы не уйти в рекурсию
8. Системно – Прочие системные выделения памяти с наивысшим приоритетом – невозможность выделения чревата крахом всей системы
Первые три приоритета при нехватке памяти просто не будут её получать. Но третий режим готов немного подождать, включив глобальный маркер.
Четвёртый приоритет будет ждать пока не будет выставлен другой глобальный маркер – информирующий о том, что с выделением памяти действительно большая проблема и простыми путями её не получить – грубо говоря, без жертв не обойдётся. Это значит, что и резервная память уже исчерпана. Текущий алгоритм скорее всего будет «падать» (в исключение или как-то иначе прерывать свою работу).
Пятый приоритет – тоже самое, что и четвёртый – но выставляет маркер требования жертв – тут могут быть завершены другие потоки (НЕ НАХОДЯЩИЕСЯ В КРИТИЧЕСКИХ СЕКЦИЯХ) – коли памяти так и не будет.
Шестой, седьмой – это специальный режим выделения памяти из алгоритмов восстановления памяти. Не начинают других процессов и нечего не ожидают.
Восьмой приоритет – то же самое, что и четвёртый – но требует немедленного выделения памяти – если никаких резервов нет – то он алгоритм «упадёт», и скорее всего потянет за собой весь процесс.
Соответственно далее обработка выделения памяти может вести себя несколько по-разному – для разных приоритетов выделения памяти. Но главное – она будет выставлять разные глобальные маркеры критичности ситуации.
Во-вторых. У нас есть отдельный поток восстановления. Он анализирует выставленные маркеры и принимает различные меры восстановления:
1. Чистит кэш
2. Сокращает буферы
3. Удаляет временные и вспомогательные объекты (которые были таковыми заранее зарегистрированы)
4. Выгружает какие-то данные, условно, на диск
5. Выполняет какую-то упаковку больших данных
6. Насильно (или поначалу мягко) завершает выполнение каких-то процессов (потоков)
Всё это делается очень аккуратно, с некоторой расстановкой приоритетов, с постоянным контролем свободной памяти.
В-третьих. Все алгоритмы восстановления стараются не выделять память на куче – но если нужно – то делать это с контролем и в режимах: Резервно, Восстановление, Системно – но чаще именно в режиме Восстановление, т.е. остальные режимы слишком специфические
В-четвёртых. Когда памяти становится достаточно - то делается некоторая задержка, в потоке восстановления, чтобы стартовали все приостановленные потоки, после чего память снова проверяется – и если её по-прежнему достаточно – снимаются кризисные маркеры и поток временно засыпает до следующей автопроверки.
В-пятых. Если восстановление так и выходит на необходимый объём памяти – выставляется маркёр отказа в обслуживании – все запросы памяти получают отказ – и алгоритмы, как и потоки сворачиваются – приложение устремляется к некоторой базисной точке – происходит глобальная чистка памяти – далее приложение перезапускает свою работу – но если памяти по-прежнему не хватает – приложение окончательно «падает»
Я бы не стал связывать сей лозунг с идеями коммунизма или социализма. Но мой взгляд - самый что ни на есть тоталитарный (возможно тоталитарно демократический - если таковым считать нынешний демократический курс прогрессивного запада) лозунг. Где слова - лишь ширма, за которой скрывается многослойное общество, либо увязшее во взаимном контроле, либо жёстко насильно подчинённое высшей власти; где лишь верхушка этого улия может хоть как-то чувствовать себя свободными - но и это скорее всего утопия - там тоже царствуют законы взаимосдерживания, просто сдерживают там лишь необъятные амбиции, а не повседневные потребности!
Все, кто ниже - неявно угнетаются и подчиняются общим законам и устремлениям, диктуемым сверху. Если кто-то ещё в состоянии быть против - он отвергается (искореняется системой) - и существует вне её! Так что это не утопия - это скорее антиутопия! Пример - вот фильм Разрушитель, например. Или сериал Экспансия - где очень тонко было показано всё натяжение между разными слоями общества (и речь даже не про астеров, на той же Земле всё очень даже не гладко). Ещё одна такая утопия (где, правда будущее показано лишь вскользь - зато очень в опасном ключе за розовой ширмой) - это сериал Континуум. Просто в Звёздном пути в это решили не углубляться - сказка для детей же, а не политический триллер для взрослых!
А такой лозунг из "Звёздного пути" очень явно намекает на то - что жизнями простых смертных там явно движет что-то другое.... что даже назвать страшно!
Формально согласен - при восстановлении соединения номер сокета не должен играть ключевую роль - иначе - это архитектурная ошибка. Другое дело - что если удалённая сторона и её архитектура от Вас никак не зависит, и приходится работать с тем что есть
Но - тут сохранить номер сокета вообще не проблема даже при нехватке памяти
А вот это не всегда архитектурно удобно! И фактически отменяет более половины всех преимуществ исключений. Это уже другая тема
Я Вам отвечал на Ваше утверждение, что любой объект можно пересоздать объект. И как выкручиваться, когда это сделать невозможно, но нужно обработать исключение где-то выше по стеку
Тут какое-то непонимание ситуации. Что мы вообще обсуждаем?
Я так понял обсуждаем то, что объект может являться ресурсом, который создаётся на время выполнения какого-то кода - после чего финалится и освобождается
Но возникновение исключения не позврляет отрабоать всей секции кода до конца - и объект может быть зафинален и освобождён. Но затем мы делаем восстановление роботоспособности - и нам нужен этот самый объект для продолжения работы.
Выше я рассказал и то, как можно поступать в таких случаях
И то, что не все объекты можно вот так взять и пересоздать!
Безусловно - всё что можно пересоздать - можно и пересоздать! Но, даже, например, при взаимодействии с СУБД - не факт, что новая выборка Вам вернёт те же данные. А Вам нужны исходные - чтобы завершить начатый процесс, который если корректно не завершить со старыми данными - то хрен знает что случится тогда!
То есть, с некоторыми данными действительно надо быть аккуратными и не терять! Даже если формально есть процесс получения новых! Вот только есть ли уверенность на 100% что всё будет стабильно при повторном получении?
А вот это я не вообще не понял. Напомню - что тут обсуждение работы в кризисной ситуации - в частности ситуации нехватки памяти!
Дополнил комментарий (хотя и так должно быть понятно), прочитайте ещё раз. Если по-прежнему не понятно почему - я навряд ли до Вас доведу эту мысль
Хотя... ну вот другой пример без кода:
У Вас приложение взаимодействует скажем с онлайн магазином билетов - вы купили билет и потратили на него деньги - получили билет в виде электронного объекта. Утрата объекта = утрата билета. Да - Вы можете получить новый билет из магазина - но Вам снова придётся потратить деньги. Билеты не будут идентичны - и могут даже выполнять одну и ту же функцию, но Вы потратили повторно деньги.
А если это лотерейные билеты - то вопрос выполнения одной и той же функции становится острее - вроде бы одна и та же: функция вероятности получения выигрыша (и эта вероятность от вашего приложения даже не зависит) - вот только это два разных билета - и факт в том, что любой из них в какой-то момент может выиграть - первый или второй! Но первый уже безвозвратно потерян... А за второй Вы и так уже заплатили повторно!
Идентичный объект выше стабильно пересоздать будет невозможно, чтобы функция GetData() вернула тот же результат
Где функция giveData() условно может быть любой, связанной с неким неконстантным процессом
Но в данном случает такой объект можно выгрузить и загрузить.
но у поля _myData тут простой числовой тип. Но это мог бы быть некий тип, к конструктору которого вообще нет доступа - данные которого создаёт какой-то "чужой" процесс - хотя останется желание выгрузить загрузить его условно побитово - а если там будут ссылки на другие объекты в куче?
Так что с воссозданием объектов всё действительно не так гладко в С++
А насчёт нужности - представьте что этот объект криптоключ, открывающий доступ ко всем рабочим данным. Действующий некоторое время или в течение некоторого процесса, а потом меняющийся - но получение нового требует передачи старого! Область валидности ключа может быть жёстко ограничена областью кода - в котором криптоключ является ресурсом (получается для использования и возвращается назад при завершении работы), но сбой может выкинуть выполнение из области кода использования ключа (при невозможности корректно обработать все процессы обслуживания ключа, в кризисной ситуации) - а возобновление работоспособности приложения потребует сохранение исходного ключа!
Но тут нет технических ограничений в C++ - нужно лишь правильно выстраивать архитектуру владения ключом (ссылки на объект) , в т.ч. при обработке сбоев!
У вас тут спор об особенностях той или иной архитектуры. Он пустой. При любом раскладе всегда можно найти то или иное решение для конкретного случая. А сферическую лошадь в вакууме тут рассматривать бессмысленно!
Но соглашусь с тем что не все объекты всегд можно создать повторно без существенного изменения состояния приложения . Тут просто вопрос иначе надо ставить (для случая кризисной ситуации, в шаге от падения всего приложения):
Что ценнее потерять идентичность какого-то объекта или положить всё приложение?
Можно ли временно выгрузить такой объект (или его важную часть) из памяти, на время восстановления работоспосоности, а потом загрузить её обратно и восстановить идентичность объекта
А правильная ли архитектура работы с такими ценными объектами? Может нужно их держать как-то иначе - чтобы они не терялись в некотором кризисном процессе? В т.ч. вклчив пометку кризисного состояния - не удалять их, при раскрутке стека (хотя тут могут быть организационные сложности при использовании стандартных механизмов отслеживания зоны владения), а сохранять на них ссылку в отдельной области памяти (видимо заранее выделенной), чтобы потом (при, условном, рестарте, не создавать их заново, а взять готовые)
А есть ли ссылки на этот объект (и ссылки внутри объекта) и что с ними делать при его восстановлении?
Сопроводительное письмо всегда было действенным аргументом
Неужели рынок вакансий питониста так перегрет - что откликов на вакансию легко может быть больше 1000? Это по России или по миру?
Наготовили кучу зелёных "специалистов" а работы столько для них нет?
Я всегда предлагал новичкам как первый проф язык учить Java, JavaScript, C# - тут найти вакансию новичку будет проще. С недавних пор тем, кто хочет в мобилки пойти - можно Kotlin порекомендовать (хотя Kotlin это не только мобилки - но это уже темя не для новичков)... но всё же лучше начать с указанной троицы. Swift - на свой страх и риск в России, тоже лучше изучать после ЯП из указанных выше. Как и SQL - кто хочет в СУБД
Python - если преподавали в школе - хорошо - но затем лучше всё-таки изучить ещё один ЯП. Для карьеры в проф-сфере тоже может быть хорошо - но уже для тех, кто с опытом! И опыт тут хорошо набирать применяя этот ЯП как вспомогательный, или переходить на него с другого ЯП, уже в процессе работы над проектами для другого ЯП
Да я не про Вас... я же не знаю кто поставил
но интересно было бы понять причину
При каких условия теоретически образуется гравистар? И каковы граничные значения количества его оболочек? И что это вообще за оболочки, чекго?