Возможно нет, но учитывая опыт wordpress — кто знает?
Надеюсь меня не спалят, если поделюсь некоторыми деталями, которые могут скомпрометировать устройство:
— приватный ключ пользователя хранится практически в открытом виде на устройстве(мы не знаем оригинальный пароль, только его derivation). Это необходимо для того, чтоб устройство могло автоматически логиниться. Какие последствия — если есть непосредственный доступ к flash — можно считать ключ. Это, конечно, крайняя мера. В худшем случае в нашем софте дыра и из сети можно вытянуть этот ключ. Я надеюсь, что мы защищены от этого поскольку мы используем одну из последних libssl с закрытыми дырами типа heartblead и уделяем максимум внимания безопасности. Да, мы стараемся держать уровень безопасности на самом высоком уровне, насколько это возможно. В нашем случае безопасность имеет приоритет выше стабильности софта.
— траффик проходя через шлюз дешифруется перед передачей другой ячейке(особенность libssl). Эта проблема в данный момент решается и это одна из главных задач, которую мой коллега пытается решить. В будущем мы попробуем вообще избежать подобных казусов используя прямое соединение между ячейками(UDP hole punching). Хотел бы подчеркнуть что мы не имеем физического доступа к дешифрованным данным. Да, мы могли бы изменить наш софт таким образом что дампить дешифрованный траффик, но никто в этом не заинтересован.
— dejstvitel'no, kompanija imeet dostup k ustrojstvu na dannyj moment. Ja nadejus' menja ne uvoljat za razglashenie dannoj informacii. Prichina prosta — dlja analiza neispravnostej. V svjazi s mnogochislennymi problemami s diskami, obnaruzheniem ustrojstva v seti prosto bylo neobhodimo dobavit' jetu funkcional'nost'. Dostup imeet tol'ko 3 cheloveka(ja ne v ih chisle). Ja uveren, chto kak tol'ko produkt stabiliziruetsja — jeta funkcija budet otkljuchena.
— последнее — авто обновление прошивки. Я лично против этого, но в данный момент это неизбежно, поскольку мы исправляем весьма критические баги в производительности и поддержании целостности данных.
В любом случае наши инженеры не заинтересованы в хищении данных. Это гики такие же как и вы все. Когда я спрашивал — что если мы продадим наш софт на сторону, то мне сказали, что продать-то мы можем, но только в том виде, в котором мы даем пользователям(закрытом, или я надеюсь в обозримом будущем — открытом).
У нас сейчас сумки на работе — «Imagine all your sex tapes in cloud ;)». Надеюсь наш настрой поддержит сообщество geektimes!
Ну, а насколько безопасен ownCloud? То, что это OpenSource еще не говорит о надежности.
Я бы сам был бы рад, чтоб код Lima был открыт, но это пока что наш хлеб =) при такой бизнес модели.
С нового устройства можно запросто войти из внешней сети. Проблема только в изначальной привязке Lima к учетной записи.
Мне лично самому не нравится идея этой регистрации, но если вам нужен доступ из любой сети — по другому я не вижу как. Тот же принцип, что и у torrent.
Поскольку код приложения закрыт — никак не могу доказать. Тут тот же уровень доверия, что и в случае с другими облачными решениями.
Я надеюсь, что в какой-то момент софт(по крайней мере core) будет открыта. В данный момент таких планов нет =/.
В теории, имея закрытый ключ вы можете дешифровать траффик и определить что именно Lima пересылает. Тут секретов нет, я даже помогу с внутренним форматом сообщений, хотя там ничего сложного нет.
Lima не пересылает никакой приватной информации на сервер.
Вот полный список данных которые хранятся на сервере:
— спискок устройств(идентификатор, тип, последнее время в сети). Используется для обнаружения других устройств привязанных к учетной записи
— данные о учетной записи(приватный ключ передается, но он защищен паролем пользователя, так что без параля невозможно дешифровать данные)
Никто кроме пользователя не имеет доступа ни к одному из устройств.
По случаю я принимаю участие в разработке Lima(присоединился к проекту 5 месяцев назад).
Насчет неограниченного объема — имеется в виду, что можно подключить диск любого размера. В данный момент поддерживается только один диск. В ближайшей версии будет поддерживаться репликация(aka RAID 1) при наличии 2х устройств.
Поскольку внутри Lima распределенная файловая система это также будет влиять на скорость отдачи(поддерживается обращение к данным лежащим на разных ячейках).
Действительно, при синхронизации пересылается только метаданные дерева ФС. Сами данные — по требованию. Есть, конечно, разные плюшки типа локального кэша и возможности «прикрепить» файл к локальному устройству(грубо говоря скачать и держать пока файл не удален либо не снят флаг «pin»).
Касательно регистрации — необходимо чтоб клиент находился в той же сети, что и Lima, таким образом Lima привязывается к учетной записи.
В этот момент на устройстве генерируется пара ключей защищенная паролем пользователя, а публичный ключ отправляется на сервер(это нужно для того, чтоб можно было подключится к устройству находясь в другой сети) и необходимо передавать данные через relay. В текущей версии не используется UDP/TCP hole punching по ряду технических причин.
Если будет интересно — я постараюсь ответить на технические вопросы как инсайдер.
Осталось только услышать ответ эксперта по поводу использования голого async/await без сторонних библиотек типа tornado(ok, asyncio встроен в python, но он же не реализует все на свете). Собственно меня смущает как coroutine запускается(см. второй кусок кода из моего первого комментария). С time.sleep понятно(хотя не логично — могли бы допилить), но вызов в цикле который прерывается по исключению StopIteration — как по мне либо выглядит убого.
На вопрос зачем — а вдруг я не хочу тянуть весь asyncio просто потому, что хочу баловаться python на устройстве с ограниченными ресурсами.
Грубо говоря тоже самое, что и в моем примере, только без future-like object.
Я так понял наше недопонимание возникло из-за этого самого furure-like object. Как я упоминал ранее — хотел на самом деле пощупать что оно такое. Исходя из ваших ответов, я не представляю что это за фрукт но все-таки хотелось бы понять суть awaitable объекта и почему по вашему мнению он здесь не клеится.
Посмотрел на ваш следующий пример и еще раз вам пишу, вы используете сопрограммы в подходе как использовали бы функции обратного вызова. Зачем? Сформулируйте мне какую задачу реализовываете в примере. Я дам свой пример, возможно это поможет разобраться. А возможно задача у вас вообще не укладывающееся в async/awaite, и пытаясь ее все же решить через coroutine вы приходите к таким странным вещам как сопрограммы делающие только то, что дожидающиеся своего завершения.
Замените asyncio.sleep на что-то вроде loop.sock_sendall+loop.sock_recv. Так лучше понятна задача? Использовал asyncio.sleep для эмуляции задержек в качестве примера.
Задача такова — есть список друзей, нужно всех пригласить на праздник. Чтоб пригласить на праздник сначала нужно дозвониться(ping), потом уговорить прийти(handshake). Представим, что я могу звонить всем одновременно, и пока один тупит — могу говорить с другим. Пока говорю с одним — все ждут. Собственно под этим я и понимаю coroutines в single-threaded event loop.
Почему я не могу использовать coroutines в данном примере? Как бы вы реализовали эту задачу?
Возможно необходимо было использовать `s/say/invite/`чтоб было более очевидно, согласен.
Ради наглядности переписал бы как-то так:
import asyncio
import logging
from random import random
logging.getLogger().setLevel(logging.DEBUG)
class dialog:
def __init__(self, name, latency):
self.name = name
self.latency = latency
async def call(self):
logging.debug('calling {}'.format(self.name))
await asyncio.sleep(self.latency/2+random())
return 'OK'
async def convince(self):
logging.debug('convincing {}'.format(self.name))
await asyncio.sleep(self.latency/2+random())
return 'OK'
def __await__(self):
res = yield from asyncio.wait_for(self.call(), None)
assert res == 'OK'
res = yield from asyncio.wait_for(self.convince(), None)
assert res == 'OK'
logging.debug('invited {}'.format(self.name))
return 'OK'
async def invite(name, latency):
return await dialog(name, latency)
async def invite_friends():
friends = [
# (name, latency)
('mark', 0.5),
('bob', 0.3),
]
coros = [invite(name, latency) for name, latency in friends]
res, _ = await asyncio.wait(coros)
assert all(([x.result() == 'OK' for x in res]))
loop = asyncio.get_event_loop()
loop.run_until_complete(invite_friends())
Зачем вам syscall table? filp_open, vfs_read уже не в моде?
Я применял kallsyms_lookup_name только когда писал модуль установки HW WP на уровне ядра(на то время такого финта не существовало, да и сейчас скорее всего нет такой фишки). Другого применения не вижу.
Не обижайтесь, но вы либо совсем ничего не поняли, либо ваш опыт использования кода на callback, был категорически против загрузки в голову :) материала про coroutine. Видно четко, что вы не поняли преимуществ, которые дает использование сопрограмм и пытались притянуть в примеры концепцию функций обратного вызова.
Я не обижаюсь, а пытаюсь разгрести кашу в голове. С coroutine я знаком — libevent в C, Fiber в ruby — в данных случаях у меня не возникало проблем с пониманием. В вашем примере сложно отследить что за чем следует. Да, если использовать coroutine_start и закрыть глаза на все остальное — ничего сложного. К стати не совсем понятно зачем `current.append(coro)` в `switch_to` — чтоб поддерживать бесконечный цикл в `hello`? Зачем там вообще бесконечный цикл? Если убрать бесконечный цикл, то обьект sleep не будет функционировать правильно(список current всегда будет содержать лишние `hello`) и, если я правильно понимаю, в определенный момент выскочит исключение.
В своем примере я попытался опробовать coroutine generator и вложенные вызовы этих же coroutine.
Сопрограмма созданная вызовом hello у вас завершается не успев сделать чего-то существенного, кроме ожидания своего завершения.
Ну как же — запускает coroutine `poke`. Да, не возвращает результат, но это пример сказать «привет» — считайте keep-alive.
Зачем вы создаете и запускаете другую сопрограмму в await объекте?
Возможно пример получился неудачный, но в данном случае я хотел просто вызвать еще один await, почему бы и нет?
Добавление «world.», может я не понял идеи. Если это для ограничение итераций, то подход абсолютно неверный — в самой короутине это можно и нужно сделать.
В данном случае чтоб избежать бесконечной рекурсии. Да, лучше бы вызвал не hello, а что-то другое.
Функции asyncio такие как sleep, wait, etc. уже возвращают awaitable объект. Использовать с ними yield from не надо.
Если я правильно понимаю, то в `__await__` можно использовать либо `yield from` либо `return`. Python3.5 не разрешает использовать `await` в `__await__`
def friends() — это просто неоправданное увеличение энтропии :)
Не совсем понятно данное утверждение.
Попытался соорудить более понятный пример, в котором я приглашаю друзей на «вечеринку»:
import asyncio
async def say(name, what, timeout):
return await poke('{} {}'.format(what, name), timeout)
async def ping(timeout):
await asyncio.sleep(timeout)
return 'OK'
async def handshake(timeout):
await asyncio.sleep(timeout)
return 'OK'
class poke:
def __init__(self, name, timeout):
self.name = name
self.timeout = timeout
def __await__(self):
res = yield from asyncio.wait_for(ping(0.1), None)
assert res == 'OK'
res = yield from asyncio.wait_for(handshake(0.1), None)
assert res == 'OK'
return 'OK'
async def invite_friends():
res, _ = await asyncio.wait([
say("friends", 'hello', 0.5),
say("neighbours", 'hello', 0.3),
])
assert all(([x.result() == 'OK' for x in res]))
loop = asyncio.get_event_loop()
loop.run_until_complete(invite_friends())
Возможно я не понимаю основное идеи Future-like объектов? В моем случае можно было бы и обойтись `async coroutine`, конечно. Возможно Вы сможете дать наглядный пример использования подобных объектов?
Также все еще интересно увидеть комментарии ко второй части моего оригинального поста.
Если честно, то конструкция await/async не слишком выразительна. Какая-то мешанина из обработчиков и генераторов.
На практике я python3 не использую, потому мои наблюдения могут не иметь смысла.
Попытался сочинить что-то идя по вашим стопам и докам в сети, получилось такое:
import asyncio
async def hello(name, timeout):
await poke(name, timeout)
class poke:
def __init__(self, name, timeout):
self.name = name
self.timeout = timeout
def __await__(self):
yield from asyncio.sleep(self.timeout) # say hello
if not self.name.startswith("world"):
yield from asyncio.wait([hello("world.{}".format(self.name), 0.3)])
yield
async def friends():
await asyncio.wait([
hello("friends", 0.5),
hello("neighbours", 0.3),
])
loop = asyncio.get_event_loop()
loop.run_until_complete(friends())
Вроде все понятно. А теперь я решил включить мозги и попробовать без asyncio:
import time
async def hello(name, timeout):
await poke(name, timeout)
class poke:
def __init__(self, name, timeout):
self.name = name
self.timeout = timeout
def __await__(self):
time.sleep(self.timeout) # say hello
if not self.name.startswith("world"):
coro = hello("world.{}".format(self.name), 0.3)
while True:
try:
coro.send(None)
yield
except StopIteration:
break
yield
async def friends():
coros = [
hello("friends", 0.5),
hello("neighbours", 0.3)
]
for coro in coros:
coro.send(None)
for coro in coros:
await coro
poll = friends()
while True:
try:
poll.send(None)
except StopIteration:
break
Второй вариант выглядит коряво и асимметрично. В чем дело? Так и должно быть?
Почему нельзя вызывать `await` в `__await__` методе? Почему для `friends` я также не могу вызвать `await`, но должен в цикле слать `send`?
Также я заметил, что порядок выполнения разный, хотя все стадии проходит в обоих случаях. Если честно, то не совсем понятно почему так получается.
Отдельно хотелось бы раскритиковать заголовок — в данном случае не представлен алгоритм позволяющий отсортировать массив в условиях жесткого ограничения, а рассмотрены сомнительные приемы зависимые от операционной системы.
В моей практике довольно часто встречаются случаи, когда система имеет 32MB памяти, 0MB swap и накопитель — NOR FLASH — в данном случае действительно приходится выкручиваться, и никакие mmap не помогут.
Про mmap — все неверно.
Во первых когда мапится файл — ядро к swap не прикасается — чистые страницы отбрасываются, грязные — пишутся на накопитель, потом отбрасываются.
Во вторых при анонимном mmap — это тоже самое, что и sbrk — при нехватке ядро вымещает страницы в swap. Разница между mmap и sbrk в том, что можно сделать munmap в то время как unsbrk не существует.
Также имеет смысл упомянуть что подавляющее большинство аллокаторов использует mmap, а sbrk — только в системах которые не поддерживает mmap, что в данный момент большая редкость.
Если есть физический доступ к устройству более чем на 10 минут я уверен, что найдутся умельцы которые вскроют устройство, подключатся к flash напрямую и загонят нужный бэкдор.
Полностью согласен с Google, что это баг несущественный. Возможно, были возмущены неверные супруги =).
Ну а если кто-то ходит на дискотеки и оставляет свой телефон на столе без присмотра — че уже париться-то?
Подобная проблема возникает при циклических зависимостях.
В C++11 для этого есть std::weak_ptr. В сети полно статей о том как это работает.
Если я правильно понял реализацию, то weak_ptr и shared_ptr используют(разделяют) специальный объект, который управляет 2мя счетчиками — weak и strong. Оригинальный обьект удаляется когда strong_count == 0, а сам объект счетчика уничтожается когда weak_count == 0. Главная идея в том, что сам shared_ptr понимает о существовании weak_ptr. При разыменовании weak_ptr проверяется значение strong_count и если оно равно 0 — попытка завершается неудачей.
Я, как диванный эксперт, хотел бы дополнить, что излучение Хокинга — это поглощение античастицы (с отрицательной энергией) черной дырой, что влечет к уменьшению массы черной дыры. Получается, что масса черной дыры уменьшается, но информация попавшая внутрь (от частиц с положительной энергией) не может вырваться наружу.
Через определенное количество миллиардов(тут не знаю сразу ставить сотен или тысяч) масса ЧД будет мала настолько, что она исчезнет, и получается, что информация попавшая туда безвозвратно пропала. В данном случае есть теории, что информация уходит через червоточины за сингулярность.
Возможно, что при этом процессе увеличивается плотность этой самой дыры, и когда вся система придет в нестабильное состояние(какая-то критическая плотность плотность при недостаточной энергии) произойдет очередной большой взрыв.
Получается сферический конь в вакууме.
Во первых ISA может быть таковой, что размер инструкции 16 бит, а машинное слово 32 бит. Во вторых если уж идеализировать — вы знакомы с mill CPU. Хотя я не согласен с автором насчет ISA(VLIW уже провалилась у intel), он излагает весьма, весьма веские доводы в пользу свое архитектуры(черпает много из DSP, что в принципе логично учитывая текущие задачи CPU — декодирование аудио, видео, распознавание образов и текстов). Я бы скорее отнес mill CPU к универсальным DSP, а как основной CPU поставил бы RISC.
Вы упомянули, что у вас уже есть готовая ISA — можете поделиться?
Вы знакомы с lock contention? Не приходит на ум русский термин. Суть в том, что сами сообщения не тяжеловесны, но вот когда они нагружают шину одновременным доступом — производительность X АЛУ проседает практически до 1.
Надеюсь меня не спалят, если поделюсь некоторыми деталями, которые могут скомпрометировать устройство:
— приватный ключ пользователя хранится практически в открытом виде на устройстве(мы не знаем оригинальный пароль, только его derivation). Это необходимо для того, чтоб устройство могло автоматически логиниться. Какие последствия — если есть непосредственный доступ к flash — можно считать ключ. Это, конечно, крайняя мера. В худшем случае в нашем софте дыра и из сети можно вытянуть этот ключ. Я надеюсь, что мы защищены от этого поскольку мы используем одну из последних libssl с закрытыми дырами типа heartblead и уделяем максимум внимания безопасности. Да, мы стараемся держать уровень безопасности на самом высоком уровне, насколько это возможно. В нашем случае безопасность имеет приоритет выше стабильности софта.
— траффик проходя через шлюз дешифруется перед передачей другой ячейке(особенность libssl). Эта проблема в данный момент решается и это одна из главных задач, которую мой коллега пытается решить. В будущем мы попробуем вообще избежать подобных казусов используя прямое соединение между ячейками(UDP hole punching). Хотел бы подчеркнуть что мы не имеем физического доступа к дешифрованным данным. Да, мы могли бы изменить наш софт таким образом что дампить дешифрованный траффик, но никто в этом не заинтересован.
— dejstvitel'no, kompanija imeet dostup k ustrojstvu na dannyj moment. Ja nadejus' menja ne uvoljat za razglashenie dannoj informacii. Prichina prosta — dlja analiza neispravnostej. V svjazi s mnogochislennymi problemami s diskami, obnaruzheniem ustrojstva v seti prosto bylo neobhodimo dobavit' jetu funkcional'nost'. Dostup imeet tol'ko 3 cheloveka(ja ne v ih chisle). Ja uveren, chto kak tol'ko produkt stabiliziruetsja — jeta funkcija budet otkljuchena.
— последнее — авто обновление прошивки. Я лично против этого, но в данный момент это неизбежно, поскольку мы исправляем весьма критические баги в производительности и поддержании целостности данных.
В любом случае наши инженеры не заинтересованы в хищении данных. Это гики такие же как и вы все. Когда я спрашивал — что если мы продадим наш софт на сторону, то мне сказали, что продать-то мы можем, но только в том виде, в котором мы даем пользователям(закрытом, или я надеюсь в обозримом будущем — открытом).
У нас сейчас сумки на работе — «Imagine all your sex tapes in cloud ;)». Надеюсь наш настрой поддержит сообщество geektimes!
Я бы сам был бы рад, чтоб код Lima был открыт, но это пока что наш хлеб =) при такой бизнес модели.
Мне лично самому не нравится идея этой регистрации, но если вам нужен доступ из любой сети — по другому я не вижу как. Тот же принцип, что и у torrent.
Я надеюсь, что в какой-то момент софт(по крайней мере core) будет открыта. В данный момент таких планов нет =/.
В теории, имея закрытый ключ вы можете дешифровать траффик и определить что именно Lima пересылает. Тут секретов нет, я даже помогу с внутренним форматом сообщений, хотя там ничего сложного нет.
Вот полный список данных которые хранятся на сервере:
— спискок устройств(идентификатор, тип, последнее время в сети). Используется для обнаружения других устройств привязанных к учетной записи
— данные о учетной записи(приватный ключ передается, но он защищен паролем пользователя, так что без параля невозможно дешифровать данные)
Никто кроме пользователя не имеет доступа ни к одному из устройств.
Насчет неограниченного объема — имеется в виду, что можно подключить диск любого размера. В данный момент поддерживается только один диск. В ближайшей версии будет поддерживаться репликация(aka RAID 1) при наличии 2х устройств.
Поскольку внутри Lima распределенная файловая система это также будет влиять на скорость отдачи(поддерживается обращение к данным лежащим на разных ячейках).
Действительно, при синхронизации пересылается только метаданные дерева ФС. Сами данные — по требованию. Есть, конечно, разные плюшки типа локального кэша и возможности «прикрепить» файл к локальному устройству(грубо говоря скачать и держать пока файл не удален либо не снят флаг «pin»).
Касательно регистрации — необходимо чтоб клиент находился в той же сети, что и Lima, таким образом Lima привязывается к учетной записи.
В этот момент на устройстве генерируется пара ключей защищенная паролем пользователя, а публичный ключ отправляется на сервер(это нужно для того, чтоб можно было подключится к устройству находясь в другой сети) и необходимо передавать данные через relay. В текущей версии не используется UDP/TCP hole punching по ряду технических причин.
Если будет интересно — я постараюсь ответить на технические вопросы как инсайдер.
Осталось только услышать ответ эксперта по поводу использования голого async/await без сторонних библиотек типа tornado(ok, asyncio встроен в python, но он же не реализует все на свете). Собственно меня смущает как coroutine запускается(см. второй кусок кода из моего первого комментария). С time.sleep понятно(хотя не логично — могли бы допилить), но вызов в цикле который прерывается по исключению StopIteration — как по мне либо выглядит убого.
На вопрос зачем — а вдруг я не хочу тянуть весь asyncio просто потому, что хочу баловаться python на устройстве с ограниченными ресурсами.
Грубо говоря тоже самое, что и в моем примере, только без future-like object.
Я так понял наше недопонимание возникло из-за этого самого furure-like object. Как я упоминал ранее — хотел на самом деле пощупать что оно такое. Исходя из ваших ответов, я не представляю что это за фрукт но все-таки хотелось бы понять суть awaitable объекта и почему по вашему мнению он здесь не клеится.
Замените asyncio.sleep на что-то вроде loop.sock_sendall+loop.sock_recv. Так лучше понятна задача? Использовал asyncio.sleep для эмуляции задержек в качестве примера.
Задача такова — есть список друзей, нужно всех пригласить на праздник. Чтоб пригласить на праздник сначала нужно дозвониться(ping), потом уговорить прийти(handshake). Представим, что я могу звонить всем одновременно, и пока один тупит — могу говорить с другим. Пока говорю с одним — все ждут. Собственно под этим я и понимаю coroutines в single-threaded event loop.
Почему я не могу использовать coroutines в данном примере? Как бы вы реализовали эту задачу?
Возможно необходимо было использовать `s/say/invite/`чтоб было более очевидно, согласен.
Ради наглядности переписал бы как-то так:
Я применял kallsyms_lookup_name только когда писал модуль установки HW WP на уровне ядра(на то время такого финта не существовало, да и сейчас скорее всего нет такой фишки). Другого применения не вижу.
Я не обижаюсь, а пытаюсь разгрести кашу в голове. С coroutine я знаком — libevent в C, Fiber в ruby — в данных случаях у меня не возникало проблем с пониманием. В вашем примере сложно отследить что за чем следует. Да, если использовать coroutine_start и закрыть глаза на все остальное — ничего сложного. К стати не совсем понятно зачем `current.append(coro)` в `switch_to` — чтоб поддерживать бесконечный цикл в `hello`? Зачем там вообще бесконечный цикл? Если убрать бесконечный цикл, то обьект sleep не будет функционировать правильно(список current всегда будет содержать лишние `hello`) и, если я правильно понимаю, в определенный момент выскочит исключение.
В своем примере я попытался опробовать coroutine generator и вложенные вызовы этих же coroutine.
Ну как же — запускает coroutine `poke`. Да, не возвращает результат, но это пример сказать «привет» — считайте keep-alive.
Возможно пример получился неудачный, но в данном случае я хотел просто вызвать еще один await, почему бы и нет?
В данном случае чтоб избежать бесконечной рекурсии. Да, лучше бы вызвал не hello, а что-то другое.
Если я правильно понимаю, то в `__await__` можно использовать либо `yield from` либо `return`. Python3.5 не разрешает использовать `await` в `__await__`
Не совсем понятно данное утверждение.
Попытался соорудить более понятный пример, в котором я приглашаю друзей на «вечеринку»:
Возможно я не понимаю основное идеи Future-like объектов? В моем случае можно было бы и обойтись `async coroutine`, конечно. Возможно Вы сможете дать наглядный пример использования подобных объектов?
Также все еще интересно увидеть комментарии ко второй части моего оригинального поста.
На практике я python3 не использую, потому мои наблюдения могут не иметь смысла.
Попытался сочинить что-то идя по вашим стопам и докам в сети, получилось такое:
Вроде все понятно. А теперь я решил включить мозги и попробовать без asyncio:
Второй вариант выглядит коряво и асимметрично. В чем дело? Так и должно быть?
Почему нельзя вызывать `await` в `__await__` методе? Почему для `friends` я также не могу вызвать `await`, но должен в цикле слать `send`?
Также я заметил, что порядок выполнения разный, хотя все стадии проходит в обоих случаях. Если честно, то не совсем понятно почему так получается.
В моей практике довольно часто встречаются случаи, когда система имеет 32MB памяти, 0MB swap и накопитель — NOR FLASH — в данном случае действительно приходится выкручиваться, и никакие mmap не помогут.
Во первых когда мапится файл — ядро к swap не прикасается — чистые страницы отбрасываются, грязные — пишутся на накопитель, потом отбрасываются.
Во вторых при анонимном mmap — это тоже самое, что и sbrk — при нехватке ядро вымещает страницы в swap. Разница между mmap и sbrk в том, что можно сделать munmap в то время как unsbrk не существует.
Также имеет смысл упомянуть что подавляющее большинство аллокаторов использует mmap, а sbrk — только в системах которые не поддерживает mmap, что в данный момент большая редкость.
Полностью согласен с Google, что это баг несущественный. Возможно, были возмущены неверные супруги =).
Ну а если кто-то ходит на дискотеки и оставляет свой телефон на столе без присмотра — че уже париться-то?
В C++11 для этого есть std::weak_ptr. В сети полно статей о том как это работает.
Если я правильно понял реализацию, то weak_ptr и shared_ptr используют(разделяют) специальный объект, который управляет 2мя счетчиками — weak и strong. Оригинальный обьект удаляется когда strong_count == 0, а сам объект счетчика уничтожается когда weak_count == 0. Главная идея в том, что сам shared_ptr понимает о существовании weak_ptr. При разыменовании weak_ptr проверяется значение strong_count и если оно равно 0 — попытка завершается неудачей.
Через определенное количество миллиардов(тут не знаю сразу ставить сотен или тысяч) масса ЧД будет мала настолько, что она исчезнет, и получается, что информация попавшая туда безвозвратно пропала. В данном случае есть теории, что информация уходит через червоточины за сингулярность.
Возможно, что при этом процессе увеличивается плотность этой самой дыры, и когда вся система придет в нестабильное состояние(какая-то критическая плотность плотность при недостаточной энергии) произойдет очередной большой взрыв.
Во первых ISA может быть таковой, что размер инструкции 16 бит, а машинное слово 32 бит. Во вторых если уж идеализировать — вы знакомы с mill CPU. Хотя я не согласен с автором насчет ISA(VLIW уже провалилась у intel), он излагает весьма, весьма веские доводы в пользу свое архитектуры(черпает много из DSP, что в принципе логично учитывая текущие задачи CPU — декодирование аудио, видео, распознавание образов и текстов). Я бы скорее отнес mill CPU к универсальным DSP, а как основной CPU поставил бы RISC.
Вы упомянули, что у вас уже есть готовая ISA — можете поделиться?