Спустя столько несколько поколений стартовые условия среднего чернокожего уже вполне могли выровняться, однако это происходит в разы медленнее, чем могло бы — и причина этого в решениях самих чернокожих, которые стягивают статистику к низким показателям.
Например, есть резкий перекос в количестве полных семей между «белыми» (включая азиатов) и чернокожими (догадаетесь, в какую сторону?). Кто заставляет эти семьи распадаться — неужто заговор белых, опасающихся превосходства африканской расы?
И решение проблемы здесь, кстати, не в введении всё новых квот на обучение, которые не работают (потому что доставшееся трудом ценится выше). А в кропотливой работе по образованию людей, вроде той, что малость выдернула жителей села из оцепенения в начале прошлого века.
«Контекст IT» не относится к уважаемому grondek — это ведь не «контекст IT в понимании grondek» (видите разницу в двух фразах?). Вы же оперируете определениями отвлечёнными от IT — «master-slave в контексте потомка рабов», что есть рекурсивное определение, особенно если упомянутый потомок рабов видит только фразу «master-slave», но не видит или не хочет видеть остальной текст.
Если бабушка была бы дедушкой, у ней была бы борода и полтора яичка.
Если бы «серфинг в интернете» назывался «human trafficking», рабство называлось бы как-то ещё, и именно с рабством и следовало бы бороться, а не вырезать название явления из всего медийного пространства.
К сожалению, теперь надавить можно на любое хоть как-то публичное лицо. Найдут аккаунт в соцсетях, устроят там тебе травлю (во имя толерантности, разумеется) или даже по аккаунту в соцсетях найдут где ты живёшь, и придут под окна орать среди ночи и кидать гнилыми овощами, пугая семью и соседей. И про семью я не шучу — они уже почти пришли к своей собственной версии «семьи врага народа». Спасает разве что лень большинства активистов подниматься и идти куда-то за идею, но это только если не дойдёт до ушей по-правде неадекватных личностей.
Велосипедных ThreadLocal'ов как раз пожалуй опасаться не нужно, если экземпляр ShadowThread всё же будет тот же самый.
Другое понимание намного опаснее, так как это как раз и есть о чём я уже говорил — расчёт на то, что некий произвольный код действительно будет находить в ThreadLocal значения, оставленные там предыдущей (никак не связанной, кроме как через внешний дизайн, не выраженный в коде) задачей, а вот этого, думаю, мы как раз и не можем строго гарантировать.
Но постойте? Если блокирование на io всё равно отдаёт ресурсы файберам, для чего нужно было городить разделение Thread|Fiber? Ведь это фактически уже значит, что любой тред становится, эффективно говоря, своеобразным файбером уже благодаря этому факту. Я тут уже в нескольких ветках пытаюсь этот на этот вопрос найти ответ.
И я, кстати, не согласен, что в CPU упираться лучше. Что если я не хочу в него упираться — кто мне оставит такую опцию в настройках? Хорошо настроенный пул уже будет упираться в CPU, а так это получается опять магия, как с Common FJ-pool в Stream, разве что (может быть) с меньшим количеством дедлоков. Или с большим, если не повезёт, учитывая в что в FJ не будет миллионов конкурирующих задач.
Ситуация с parallelStream(), как мне кажется, немало народа (меня в том числе) заставила задуматься, так ли хорошо это когда любой чих может на самом деле произойти в тридевятом треде, а мне вернётся только результат.
Thread.currentThread указывает на непонятные постоянно меняющиеся значения
Почему это? Если он возвращает ShadowThread, то для конкретного Continuation'a должен возвращать один и тот же экземпляр, из чего-то вроде ContinuationLocal. Сюда же идут имя треда и всё подобное.
Вот что делать с ThreadLocal действительно неясно — я ведь сам уже столкнулся с ситуацией, когда мой неверно придуманный r/o кэш был помещён в ThreadLocal, из-за чего запросы разных пользователей получили возможность не читать самостоятельно из базы некоторые значения (без нарушения инкапсуляции сессии; правда, в реальности ускорения получено не было, так как контекст нового пользователя с большой вероятностью просто вытеснял из кэша старьё, и 90-95% данных таки приходится подгружать). В моём-то случае это неверное понимание, что я творил, а если кто-то на это на самом деле полагается для чего-то критичного?
Но то же самое нужно будет делать и для Fiber'ов.
Вряд ли Main станет Fiber'ом из-за обратной несовместимости, а перевод экосистемы на Continuation опять же потребует аккуратного дробления. Но в добавок ещё и с ограничением на блокировку.
(или нет? насколько увеличится толщина методов в java.io если они будут повсеместно проверять, запущены ли они в Fiber'ах?)
Почему бы благородному дону не сделать OSGi поверх jigsaw? Ведь сами же и сказали — OSGi делает часть проверок позже, чем jigsaw. Следовательно, если среда OSGi может доказать, что проект построен поверх jigsaw, часть собственных проверок она имеет право превратить в «arg0->true», и под это дело немного разгрузить runtime.
Вот и нашлась одна из причин, а дальше — главным образом, весы с контрпримерами, и вопросы о цене интегрирования.
[Перечитал(правда, по диагонали)]
Всё равно не особо понятно, и главным образом благодаря заявленной магии. Например обговаривается явное разделение мониторов по типу владельца — Fiber|Thread. А зачем конкретно делить? Нет, я в принципе-то понимаю, что выбор должен быть сознательным, но делить-то зачем?
Предположим, нечто заставляет системный примитив парковаться. Почему Fiber при этом может отдать мощности другому Continuation, а Thread, внезапно, не может? Разница такого порядка должна быть видна, разве что, на уровне достаточно глубоко системных процессов. Исключение, которое я могу придумать — это что кто-то (мир духу их) сохраняет ссылки на экземпляры Thread, дабы потом из другого Thread сравнить с другой ссылку по "==", и для Fiber нет механизмов, позволяющих вернуть тот же экземпляр ShadowThread? В чём-то другом? Какой предполагаемый механизм поломки? Если это просто «мы не знаем, но бывает всякий код», то возможно следует провести более подробное исследование узких мест, и всё-таки хакнуть сам Thread?
В итоге я, конечно, пророню скупую слезу по необходимости иметь в java.base растущее количество примитивов, делающих одно и то же, но с перламутровыми, а потом с и медными, пуговицами (ведь глупо сомневаться что ещё через N лет не придумают новые подходы ещё более эффективной параллелизации), но обратная совместимость есть фактор поддержания продаваемости, и придётся мириться.
Разве что стоить такой будет ну совсем не как нечто из вахтового посёлка, а скорее как посёлок целиком. Элитные клиенты же, платёжеспособные. Вот это называется — рынок порешал.
Рискну предположить, что проверку пароля при первоначальном вводе и проверку пароля в принципе писало два разных человека, имевших разную постановку задач. Также возможно, что эти две части писались в очень разное время, и одну просто не обновили для соответствия другой.
Сбербанк большой, ему видней.
Мигрировать с Java 8 сейчас очень больно, ведь модули — это немалое переосмысление сборки рантайма, а кроме модулей в Java 9 почти ничего и нет (вот кому надо было это «почти ничего» — те закусили пулю и перешли, у остальных «и так работает»).
Вместе с тем, много инструментов разработки с серьёзным отставанием реагировали на обновление версии языка, и отставанию сильно помогло упомянутое выше переосмысление. Ну там было… и проблемы с производительностью, и с потреблением памяти, и даже весьма мистическое предупреждение "(Recovered) Internal inconsistency during lambda shape analysis" — всё на коде, написанном весьма даже по JLS, и вроде даже людьми сдавшими OCP-8. Сейчас-то они[инструменты] уже, может, и догнали, а только хайп ушёл на спад. В итоге вот и приходится сгонять народ с Java 8 драконовскими датами end of life.
Вот то-то и оно. А кумулятивные обновления — по определению антагонистичны такой философии.
Хотя для меня как разработчика это тоже весьма много головной боли приносит:
— У нас вот тут баг!
— Как так, ведь мы ещё полгода назад… а, так у вас версия… :monkaS:
Оружие, огнестрельное в частности — придумано только для того, чтобы убивать
Лично я тут вижу некую аналогию с ядерным оружием, которое тоже придумано исключительно для того, чтобы кого-то (весьма неопределённого, ввиду большого радиуса поражения) убить. Тем не менее, в контексте современной политики ядерное оружие является скорее инструментом сдерживания, так как сам факт его наличия у конфликтующих сторон заставляет обе стороны принимать более взвешенные решения.
С огнестрельным оружием то же самое — его наличие у человека повышает условную "стоимость нападения" на этого человека — и, по законам рынка, снижает количество нападений в целом.
В середине 19 века доллар всё ещё был обеспечен золотом — следовательно, все эти капиталы тоже. Получается, для обеспечения таких капиталов следовало где-то брать золото. Своего золота у Америки в то время, как я понимаю, не добывалось достаточно — значит, имелся-таки приток капитала из других стран.
Я не утверждаю, что ситуация была один-в-один с нынешней — просто пытаюсь проводить параллели.
Но и развитие США до экономики #1 в своё время происходило не в вакууме.
Не берусь утверждать, что именно помогло им толчком «последней мили», так как не специалист в этом вопросе — но могу предположить, что без капитала других стран (в том числе экономики #1 того времени) там тоже не обошлось.
Например, есть резкий перекос в количестве полных семей между «белыми» (включая азиатов) и чернокожими (догадаетесь, в какую сторону?). Кто заставляет эти семьи распадаться — неужто заговор белых, опасающихся превосходства африканской расы?
И решение проблемы здесь, кстати, не в введении всё новых квот на обучение, которые не работают (потому что доставшееся трудом ценится выше). А в кропотливой работе по образованию людей, вроде той, что малость выдернула жителей села из оцепенения в начале прошлого века.
Если бы «серфинг в интернете» назывался «human trafficking», рабство называлось бы как-то ещё, и именно с рабством и следовало бы бороться, а не вырезать название явления из всего медийного пространства.
Другое понимание намного опаснее, так как это как раз и есть о чём я уже говорил — расчёт на то, что некий произвольный код действительно будет находить в ThreadLocal значения, оставленные там предыдущей (никак не связанной, кроме как через внешний дизайн, не выраженный в коде) задачей, а вот этого, думаю, мы как раз и не можем строго гарантировать.
И я, кстати, не согласен, что в CPU упираться лучше. Что если я не хочу в него упираться — кто мне оставит такую опцию в настройках? Хорошо настроенный пул уже будет упираться в CPU, а так это получается опять магия, как с Common FJ-pool в Stream, разве что (может быть) с меньшим количеством дедлоков. Или с большим, если не повезёт, учитывая в что в FJ не будет миллионов конкурирующих задач.
Ситуация с parallelStream(), как мне кажется, немало народа (меня в том числе) заставила задуматься, так ли хорошо это когда любой чих может на самом деле произойти в тридевятом треде, а мне вернётся только результат.
Почему это? Если он возвращает ShadowThread, то для конкретного Continuation'a должен возвращать один и тот же экземпляр, из чего-то вроде ContinuationLocal. Сюда же идут имя треда и всё подобное.
Вот что делать с ThreadLocal действительно неясно — я ведь сам уже столкнулся с ситуацией, когда мой неверно придуманный r/o кэш был помещён в ThreadLocal, из-за чего запросы разных пользователей получили возможность не читать самостоятельно из базы некоторые значения (без нарушения инкапсуляции сессии; правда, в реальности ускорения получено не было, так как контекст нового пользователя с большой вероятностью просто вытеснял из кэша старьё, и 90-95% данных таки приходится подгружать). В моём-то случае это неверное понимание, что я творил, а если кто-то на это на самом деле полагается для чего-то критичного?
Вряд ли Main станет Fiber'ом из-за обратной несовместимости, а перевод экосистемы на Continuation опять же потребует аккуратного дробления. Но в добавок ещё и с ограничением на блокировку.
(или нет? насколько увеличится толщина методов в java.io если они будут повсеместно проверять, запущены ли они в Fiber'ах?)
Вот и нашлась одна из причин, а дальше — главным образом, весы с контрпримерами, и вопросы о цене интегрирования.
Всё равно не особо понятно, и главным образом благодаря заявленной магии. Например обговаривается явное разделение мониторов по типу владельца — Fiber|Thread. А зачем конкретно делить? Нет, я в принципе-то понимаю, что выбор должен быть сознательным, но делить-то зачем?
Предположим, нечто заставляет системный примитив парковаться. Почему Fiber при этом может отдать мощности другому Continuation, а Thread, внезапно, не может? Разница такого порядка должна быть видна, разве что, на уровне достаточно глубоко системных процессов. Исключение, которое я могу придумать — это что кто-то (мир духу их) сохраняет ссылки на экземпляры Thread, дабы потом из другого Thread сравнить с другой ссылку по "==", и для Fiber нет механизмов, позволяющих вернуть тот же экземпляр ShadowThread? В чём-то другом? Какой предполагаемый механизм поломки? Если это просто «мы не знаем, но бывает всякий код», то возможно следует провести более подробное исследование узких мест, и всё-таки хакнуть сам Thread?
В итоге я, конечно, пророню скупую слезу по необходимости иметь в java.base растущее количество примитивов, делающих одно и то же, но с перламутровыми, а потом с и медными, пуговицами (ведь глупо сомневаться что ещё через N лет не придумают новые подходы ещё более эффективной параллелизации), но обратная совместимость есть фактор поддержания продаваемости, и придётся мириться.
Пойду-ка статью перечитаю, что ли.
Сбербанк большой, ему видней.
Вместе с тем, много инструментов разработки с серьёзным отставанием реагировали на обновление версии языка, и отставанию сильно помогло упомянутое выше переосмысление. Ну там было… и проблемы с производительностью, и с потреблением памяти, и даже весьма мистическое предупреждение "(Recovered) Internal inconsistency during lambda shape analysis" — всё на коде, написанном весьма даже по JLS, и вроде даже людьми сдавшими OCP-8. Сейчас-то они[инструменты] уже, может, и догнали, а только хайп ушёл на спад. В итоге вот и приходится сгонять народ с Java 8 драконовскими датами end of life.
Ну, это моё видение ситуации.
Хотя для меня как разработчика это тоже весьма много головной боли приносит:
— У нас вот тут баг!
— Как так, ведь мы ещё полгода назад… а, так у вас версия… :monkaS:
Лично я тут вижу некую аналогию с ядерным оружием, которое тоже придумано исключительно для того, чтобы кого-то (весьма неопределённого, ввиду большого радиуса поражения) убить. Тем не менее, в контексте современной политики ядерное оружие является скорее инструментом сдерживания, так как сам факт его наличия у конфликтующих сторон заставляет обе стороны принимать более взвешенные решения.
С огнестрельным оружием то же самое — его наличие у человека повышает условную "стоимость нападения" на этого человека — и, по законам рынка, снижает количество нападений в целом.
Я не утверждаю, что ситуация была один-в-один с нынешней — просто пытаюсь проводить параллели.
Не берусь утверждать, что именно помогло им толчком «последней мили», так как не специалист в этом вопросе — но могу предположить, что без капитала других стран (в том числе экономики #1 того времени) там тоже не обошлось.