Ловят проблемы люди не только прожив достаточно времени.
Раньше дети которые бы умерли после родов сейчас выживают. Будут ли они такие же развитые как остальные когда вырастут? Возможно. Будут ли у их детей такие проблемы во время родов? Вероятность высока, но им могут не помочь врачи — выживаемость снижается и это не иллюзия.
Как-то показывали по national geographic сюжет про рак в Исландии, кажется, могу и ошибаться где именно.
И многие люди (причём чуть ли не треть) там получают опухоли и в 30 лет и даже раньше а причина проста — они все дальние родственники и их пра-пра-...-прадед передал им этот «раковый» ген.
Но медицина позволяет им выживать и увеличивает число людей, у которых даже в молодости появляются опухоли.
Это очень спорное утверждение.
Физиологическая выживаемость ухудшается и это имеет значение, т.к. медицина не полностью нейтрализует явления от этого.
Возможно, интеллект может даже повышаться бесконечно, но у физической выживаемости есть нижний предел и называется вымиранием. И такое случалось с другими видами.
И выживаемость вида зависит не только от интеллекта, хотя бы потому, что интеллект не всегда можно применить.
Как-то друг мой покупал страховку, я пошёл с ним за компанию. Пришли в росгосстрах (ещё до того как у него отзывали лицензию страховщика).
Просим посчитать страховку — получается явно с довескам сумма.
Почему? Потому как со страхованием жизни.
А если нужен полис без него? А сотрудница «не имеет права» оформлять такие полиса.
Кто может? Ребята в таком-то кабинете в таком-то корпусе.
Пришли — там сидят какие-то люди, явно не принимающие клиентов, похлопали глазами и отправили куда нам действительно надо было — к мозгу этой системы.
Мозг представлял собой тётеньку, пьющую чай и беседующую в двумя немолодыми мужчинами-друзьями.
Сначала на аналогичные вопросы были попытки отшутиться вроде: «зачем страховать железку, жизнь важнее», «что? после смерти не нужна? ну хоть друзьям на выпивку будет». В итоге прямо сказали, что страховку продавать не будут.
Замечания по поводу договора публичной оферты также проигнорировали.
А вот вытащенный телефон и съёмку на камеру не проигнорировали.
Стали орать и возмущаться, хотели вывести нас, но не получилось. Кричали, топали ногами, чтобы прекратили съёмку.
Но на вопрос: «Отказываетесь ли вы продавать страховку без страхования жизни», — отвечали «Почему отказываемся, нет» — после чего продолжали возмущаться.
Звучали фразы о том что это «административное здание» (ясное дело не жилое), о том что вызовут охрану, полицию. Собственно, после того как мы сами стали требовать вызова полиции всё и успокоилось — иссяк фонтан причин, видимо.
Позвали девочку на приёме, сказали оформить страховку БЕЗ (именно БЕЗ) страхования жизни. Но в отместку, пугание, видимо, пригрозила на выложенное видео судом и потребовала у девочки после принести ей данные на клиента.
В моём мире юношеского максимализма если и возможно сравнивать операцию с экзаменом,
то получить недостающие знания перед операцией равноценны подготовке к экзамену перед экзаменом, а списывание на экзамене аналогично гуглению прямо во время операции.
Смысл экзаменов в том, чтобы отсеять претендентов по ряду признаков, потому как все могут быть не нужны.
Существующие знания не гарантируют квалификацию, но гарантируют её больше, нежели отсутствие.
pthreads хорош, но стоит упомянуть и про подводные камни.
Есть возможности "пронаследовать" какую-то часть окружения в поток (причём, по умолчанию это не "ничего"), но в ряде случаев вылезают WTF. Например, если в мастере был подключен автозагрузчик композера через require_once, он не подключится в потоке аналогичном образом.
Ресурсы, файловые дескрипторы и прочее не шарятся. Потому лучше стараться запускать потоки через PTHREADS_INHERIT_NONE, а внутри производить собственные подключения к БД, логи (монолог умеет писать с блокировками) и т.д.
Общение между потоком и мастер-процессом происходит с чем-то вроде сериализации, потому вы не сможете вернуть в мастер Closure, т.к. тот не сериализуем. Есть особенности и с другими типами данных, например с массивами.
Если вы захотите вернуть из потока вложенный массив и сделаете так.
$this->result = ['hello' => ['foo' => 'bar']]
То можете словить ошибку, так как это будет преобразовано в Volatile-объекты и при попытке считать данные в мастере они будут уже уничтожены сборщиком мусора.
Самый простой "способ" в таком случае, это явно приводить к массиву:
В целом, от меня общий совет — каждый поток должен быть максимально независим от мастер процесса. Обмен, по возможности, производить скалярными данными.
Также на некоторых конфигурациях систем (например у меня такое происходит Debian 7 и pthreads 3) могут вылетать ошибки сегментирования. С чем это точно связано я не знаю, но скорее всего с версиями каких-то библиотек.
Скажите пожалуйста, а поправлена ли вики? И если нет, когда будет?
В прошлый раз, когда я ей пользовался, она при редактировании больших статей просто уничтожала части текста, причём с завидной постоянностью. Да и вообще периодически сбивается форматирование, в блок кода может попасть параграф под ним и т.д.
Вот именно. Никто не мешает не использовать всякие рекурсивные eager-loading в подобных случаях, а последовательно получить 2, 5, 10 (или сколько надо) коллекций и собрать их в массив для дальнейшей работы. Особенно если связанные коллекции должны фильтроваться и сортироваться.
Я, если честно, не совсем понял как можно обрабатывать данные, чтобы получить 50 секунд. У нас на аналогичных параметрах системы (фильтр 50 тыс. товаров по EAV) в особо тяжёлых случаях 1.5 секунды.
Раньше дети которые бы умерли после родов сейчас выживают. Будут ли они такие же развитые как остальные когда вырастут? Возможно. Будут ли у их детей такие проблемы во время родов? Вероятность высока, но им могут не помочь врачи — выживаемость снижается и это не иллюзия.
Как-то показывали по national geographic сюжет про рак в Исландии, кажется, могу и ошибаться где именно.
И многие люди (причём чуть ли не треть) там получают опухоли и в 30 лет и даже раньше а причина проста — они все дальние родственники и их пра-пра-...-прадед передал им этот «раковый» ген.
Но медицина позволяет им выживать и увеличивает число людей, у которых даже в молодости появляются опухоли.
Физиологическая выживаемость ухудшается и это имеет значение, т.к. медицина не полностью нейтрализует явления от этого.
Возможно, интеллект может даже повышаться бесконечно, но у физической выживаемости есть нижний предел и называется вымиранием. И такое случалось с другими видами.
И выживаемость вида зависит не только от интеллекта, хотя бы потому, что интеллект не всегда можно применить.
Сейчас, по-сути, идёт гонка.
Просим посчитать страховку — получается явно с довескам сумма.
Почему? Потому как со страхованием жизни.
А если нужен полис без него? А сотрудница «не имеет права» оформлять такие полиса.
Кто может? Ребята в таком-то кабинете в таком-то корпусе.
Пришли — там сидят какие-то люди, явно не принимающие клиентов, похлопали глазами и отправили куда нам действительно надо было — к мозгу этой системы.
Мозг представлял собой тётеньку, пьющую чай и беседующую в двумя немолодыми мужчинами-друзьями.
Сначала на аналогичные вопросы были попытки отшутиться вроде: «зачем страховать железку, жизнь важнее», «что? после смерти не нужна? ну хоть друзьям на выпивку будет». В итоге прямо сказали, что страховку продавать не будут.
Замечания по поводу договора публичной оферты также проигнорировали.
А вот вытащенный телефон и съёмку на камеру не проигнорировали.
Стали орать и возмущаться, хотели вывести нас, но не получилось. Кричали, топали ногами, чтобы прекратили съёмку.
Но на вопрос: «Отказываетесь ли вы продавать страховку без страхования жизни», — отвечали «Почему отказываемся, нет» — после чего продолжали возмущаться.
Звучали фразы о том что это «административное здание» (ясное дело не жилое), о том что вызовут охрану, полицию. Собственно, после того как мы сами стали требовать вызова полиции всё и успокоилось — иссяк фонтан причин, видимо.
Позвали девочку на приёме, сказали оформить страховку БЕЗ (именно БЕЗ) страхования жизни. Но в отместку, пугание, видимо, пригрозила на выложенное видео судом и потребовала у девочки после принести ей данные на клиента.
Вот так и была оформлена неэлектронная страховка.
то получить недостающие знания перед операцией равноценны подготовке к экзамену перед экзаменом, а списывание на экзамене аналогично гуглению прямо во время операции.
Существующие знания не гарантируют квалификацию, но гарантируют её больше, нежели отсутствие.
pthreads хорош, но стоит упомянуть и про подводные камни.
Есть возможности "пронаследовать" какую-то часть окружения в поток (причём, по умолчанию это не "ничего"), но в ряде случаев вылезают WTF. Например, если в мастере был подключен автозагрузчик композера через require_once, он не подключится в потоке аналогичном образом.
Ресурсы, файловые дескрипторы и прочее не шарятся. Потому лучше стараться запускать потоки через PTHREADS_INHERIT_NONE, а внутри производить собственные подключения к БД, логи (монолог умеет писать с блокировками) и т.д.
Общение между потоком и мастер-процессом происходит с чем-то вроде сериализации, потому вы не сможете вернуть в мастер Closure, т.к. тот не сериализуем. Есть особенности и с другими типами данных, например с массивами.
Если вы захотите вернуть из потока вложенный массив и сделаете так.
То можете словить ошибку, так как это будет преобразовано в Volatile-объекты и при попытке считать данные в мастере они будут уже уничтожены сборщиком мусора.
Самый простой "способ" в таком случае, это явно приводить к массиву:
Подробнее здесь: http://stackoverflow.com/questions/14796674/a-php-pthreads-thread-class-cant-use-array
В целом, от меня общий совет — каждый поток должен быть максимально независим от мастер процесса. Обмен, по возможности, производить скалярными данными.
Также на некоторых конфигурациях систем (например у меня такое происходит Debian 7 и pthreads 3) могут вылетать ошибки сегментирования. С чем это точно связано я не знаю, но скорее всего с версиями каких-то библиотек.
Но в целом соглашусь. Лучше бы выпустили ещё одно DLC, которое всё бы расставило на места.
В прошлый раз, когда я ей пользовался, она при редактировании больших статей просто уничтожала части текста, причём с завидной постоянностью. Да и вообще периодически сбивается форматирование, в блок кода может попасть параграф под ним и т.д.