Ну описал насколько мог подробно, других деталей сейчас не вспомню. И да, приложение было как раз на акторах, решение — на MDCPropagatingDispatcher. Контекст терялся именно на сетевых запросах-ответах, в остальных местах вроде как все работало.
Добавлено: Я просто не уверен, что понимаю, как ThreadLocal может спасти ситуацию, если контекст нужно передать между тредами, а не оставить в текущем.
Что-то я упустил пасс руками в том месте, где ThreadLocal помог передать контекст в стороннюю библиотеку. Ну то есть понятно, когда она синхронная — это сработает. А если она асинхронная? Когда-то мучался с этим, пытался прикрутить MDC через кастомный диспетчер, как в примере выше к асинхронному сетевому приложению, но так вопрос и не решил: контекст терялся на границе запрос-ответ. То есть, запрос отправляется по сети, MDC сохраняется в ThreadLocal, а потом в этот поток приходит ответ на совершенно другой запрос, и MDC из ThreadLocal привязывается не к тому ответу. Учитывая, что там обрабатывалось до 1к параллельных запросов на пуле из 12 потоков, путаница получалась та еще. Может, существует какое-то рабочее решение этой проблемы?
Статья как раз о том, что в реальности значит "стать дядей", какие именно усилия придется для этого приложить, и каковы реальные шансы этого "становления". В сравнении с тем, если вы "прогнетесь". Выводы делает и решение принимает сам читатель, как статья может "заставить" что-то сделать?
Во-первых, изначальный комментарий не мой, я даже в офисе в данный момент не работаю. Во-вторых, мне совсем непонятно ваше стремление обязательно уравнять поголовье женщин и мужчин в профессии "программист". Вам говорят о том, что девушки при желании могут спокойно попасть в профессию, те, кто хочет — уже там, и прекрасно уживаются с мужчинами. На что вы отвечаете — то все фигня, их не половина, это проблема, надо уравнивать. Зачем? Мы же не животноводством занимаемся, и не в стаде баланс пытаем навести (хотя даже в этом случае это был бы совершенно иррациональный баланс).
Но речь идет не о «так или иначе», а конкретно о программистах.
Вот вам отличительная особенность девушек: отбросить вообще всю логику, все факты и доводы в предложении, вырвать из контекста лишь ту незначительную деталь, которая хоть как-то противоречит её тезису (а то и вообще просто лежит в параллельной плоскости),- и считать это отличным опровержением оппоненту. Сказано же:
А как тогда сквозняки действуют? Допустим, если достаточно долго обдувать, например, шею потоком холодного (или прохладного) воздуха — то через некоторое время она воспалится и начнет болеть. Именно то место, в которое дул холодный воздух.
Вы, вероятно, на клавиши смотрите, когда печатаете? Попробуйте освоить слепой десятипальцевый метод набора — весьма рекомендую, ускоряет рабочий процесс в разы. А после этого обсудим с вами кастомные кнопки на сенсорном тачбаре. И да, зачем делать целый сенсорный дисплей, как в том же MS Surface Book, когда можно сделать сенсорный тачбар! Юзеры же от такого новаторства уписаются кипятком же, это же так модно, стильно, молодежно! Ни у кого такого нет!
Но, допустим, тачбар — это дело вкуса и привычек. Давайте другие «хорошие железки» обсудим. Мне вот в 2017 году нужнен ноутбук с 64 гигами оперативки для моих профессиональных задач. Ну хотя бы 32 можно мне, а? Как, даже в линейке Pro таких нет? Серьезно? Что ж это за Pro такое? Для профессиональных кого? Пользователей почты и браузера? Ну, нет ноутбука — дайте хотя бы стационарную рабочую станцию. Mac Pro подойдет. Мне нужен с портом HDMI 2.0, чтоб я смог 4к-телевизор подключить на 60 Hz. Не? И видеокарту в нем проапгрейдить нельзя? В рабочей станции? Нельзя? Серьезно? Это что, типа такой iMac, только без монитора? Круто! Оригинально! И очень профессионально! Дайте два, ага! А как насчет DisplayPort daisy chaining, чтоб я своими пятью мониторами не 5 thunderbolt-разъемов занимал, а мог их по цепочке в один или в два воткнуть? Чтоб для внешних дисков еще порты остались, потому что внутрь дисков не добавишь. Что, снова нет? Что, только с проприетарными тандерболтными эпловскими мониторами, которые мне по характеристикам и размеру не подходят? Что, и с ними нельзя, потому что их с производства сняли?
Дальше продолжать не буду. Но да, отличный курс, эппл, так держать!
О каких хороших железяках идет речь? Mac Pro, который с 2013 года не обновлялся, и проапгрейдить там внутри ничего нельзя? Или MacBook Pro, в котором выпилили привычные мне функциональные клавиши в угоду свистоперделке под названием Touch Bar? Десять лет я просидел на маках, а теперь вот все чаще подумываю на «богомерзкий» windows перейти. Просто потому что под линуксом нативных фотошопов, лайтрумов и премьеров нет. А маки превратились уже из профессионального инструмента в аттрибут гламурных домохозяек. Ничего не имею против гламура и домохозяек, но задачи у меня с ними разные, а лейбл «Pro» к ним вообще никакого отношения не имеет.
Если я единственный человек, который в принципе заговорил о типизации акторов (безотносительно вашего фреймворка, замечу, так как мой опыт основывается исключительно на Akka+Scala) — то ваше желание сразу же внедрить подобную функциональность в ваш фреймворк лично мне кажется несколько поспешным. Если ваши пользователи им и без того довольны — то оно им может быть и не нужно.
Если же были запросы от ваших пользователей — то вам лучше поспрашивать у них, зачем им это может быть нужно. Потому что Akka — это другой фреймворк, а Scala — другой язык и другой подход к программированию. Может быть, то, что применимо и удобно на Scala и Akka — совсем ненужно, неудобно или неприменимо к вашему фреймворку и C++.
нам не нужно заботиться о том, какой интерфейс имеет объект, который дергает connection_pool::acquire
Верно, потому что при этом мы имеем тип возвращаемого значения, которое получим, вызвав метод aquire(). А чтобы узнать, можно ли вообще отправить актору сообщение aquire, что он на него ответит, и должен ли вообще отвечать — нужно лезть либо в документацию к нему, либо в исходный код, что не всегда практически осуществимо. И это сильно понижает производительность труда программиста. Мою, по крайней мере.
Я привел несколько вполне конкретных доводов из моей личной практики в пользу статической типизации акторов. Их дополнил eao197 еще парой примеров. Если вам все еще мало конкретики — то в тех же сферических холиварах "статика vs динамика" их есть еще, и к акторам это тоже вполне применимо.
Более того, есть мнение, что изначальная задумка ООП-подхода основывалась как раз на агентах, которые посылают сообщения друг другу. Но потом что-то пошло не так, и сейчас мы имеем ООП с синхронным дерганьем методов вместо пересылки сообщений. Хотя, попытки реализации объектов на сообщениях были (Objective-C, например).
Типобезопасность не является самоцелью, как я надеюсь.
Да. Как и молоток. Это лишь удобный инструмент, который помогает решить некоторые задачи. Я привык к этому инструменту, он очень плотно вписан в мой рабочий процесс. И его потеря для меня очень ощутима.
Но зачем это? Это все может решаться и без попыток подружить Модель Акторов со статической типизацией.
Мы топчемся по кругу, вы не находите? Можете прочитать всю ветку комментариев еще раз, все мои доводы там перечислены. На всякий случай обобщу: просто потому что некоторые люди предпочитают типобезопасность другим решениям. Просто потому, что некоторые люди считают, что типобезопасноть решает многие проблемы эффективнее других подходов. Просто потому, что каждый выбирает для себя инструмент, которым лично ему удобнее работать.
Ну описал насколько мог подробно, других деталей сейчас не вспомню. И да, приложение было как раз на акторах, решение — на MDCPropagatingDispatcher. Контекст терялся именно на сетевых запросах-ответах, в остальных местах вроде как все работало.
Добавлено: Я просто не уверен, что понимаю, как ThreadLocal может спасти ситуацию, если контекст нужно передать между тредами, а не оставить в текущем.
Что-то я упустил пасс руками в том месте, где ThreadLocal помог передать контекст в стороннюю библиотеку. Ну то есть понятно, когда она синхронная — это сработает. А если она асинхронная? Когда-то мучался с этим, пытался прикрутить MDC через кастомный диспетчер, как в примере выше к асинхронному сетевому приложению, но так вопрос и не решил: контекст терялся на границе запрос-ответ. То есть, запрос отправляется по сети, MDC сохраняется в ThreadLocal, а потом в этот поток приходит ответ на совершенно другой запрос, и MDC из ThreadLocal привязывается не к тому ответу. Учитывая, что там обрабатывалось до 1к параллельных запросов на пуле из 12 потоков, путаница получалась та еще. Может, существует какое-то рабочее решение этой проблемы?
Как это? Xeon на X99, например, — не десктоп? Или что имеется в виду?
Ножницы Мебиуса
Да, детка! Обнажи
своего удавасвою строку!Статья как раз о том, что в реальности значит "стать дядей", какие именно усилия придется для этого приложить, и каковы реальные шансы этого "становления". В сравнении с тем, если вы "прогнетесь". Выводы делает и решение принимает сам читатель, как статья может "заставить" что-то сделать?
Во-первых, изначальный комментарий не мой, я даже в офисе в данный момент не работаю. Во-вторых, мне совсем непонятно ваше стремление обязательно уравнять поголовье женщин и мужчин в профессии "программист". Вам говорят о том, что девушки при желании могут спокойно попасть в профессию, те, кто хочет — уже там, и прекрасно уживаются с мужчинами. На что вы отвечаете — то все фигня, их не половина, это проблема, надо уравнивать. Зачем? Мы же не животноводством занимаемся, и не в стаде баланс пытаем навести (хотя даже в этом случае это был бы совершенно иррациональный баланс).
Вот вам отличительная особенность девушек: отбросить вообще всю логику, все факты и доводы в предложении, вырвать из контекста лишь ту незначительную деталь, которая хоть как-то противоречит её тезису (а то и вообще просто лежит в параллельной плоскости),- и считать это отличным опровержением оппоненту. Сказано же:
Это так, к размышлению на тему...
о_0 ??
> Попробуйте не предполагать то, в чем вы не уверены, весьма рекомендую — значительно снижает количество ударов по лицу. ©
Но, допустим, тачбар — это дело вкуса и привычек. Давайте другие «хорошие железки» обсудим. Мне вот в 2017 году нужнен ноутбук с 64 гигами оперативки для моих профессиональных задач. Ну хотя бы 32 можно мне, а? Как, даже в линейке Pro таких нет? Серьезно? Что ж это за Pro такое? Для профессиональных кого? Пользователей почты и браузера? Ну, нет ноутбука — дайте хотя бы стационарную рабочую станцию. Mac Pro подойдет. Мне нужен с портом HDMI 2.0, чтоб я смог 4к-телевизор подключить на 60 Hz. Не? И видеокарту в нем проапгрейдить нельзя? В рабочей станции? Нельзя? Серьезно? Это что, типа такой iMac, только без монитора? Круто! Оригинально! И очень профессионально! Дайте два, ага! А как насчет DisplayPort daisy chaining, чтоб я своими пятью мониторами не 5 thunderbolt-разъемов занимал, а мог их по цепочке в один или в два воткнуть? Чтоб для внешних дисков еще порты остались, потому что внутрь дисков не добавишь. Что, снова нет? Что, только с проприетарными тандерболтными эпловскими мониторами, которые мне по характеристикам и размеру не подходят? Что, и с ними нельзя, потому что их с производства сняли?
Дальше продолжать не буду. Но да, отличный курс, эппл, так держать!
Если я единственный человек, который в принципе заговорил о типизации акторов (безотносительно вашего фреймворка, замечу, так как мой опыт основывается исключительно на Akka+Scala) — то ваше желание сразу же внедрить подобную функциональность в ваш фреймворк лично мне кажется несколько поспешным. Если ваши пользователи им и без того довольны — то оно им может быть и не нужно.
Если же были запросы от ваших пользователей — то вам лучше поспрашивать у них, зачем им это может быть нужно. Потому что Akka — это другой фреймворк, а Scala — другой язык и другой подход к программированию. Может быть, то, что применимо и удобно на Scala и Akka — совсем ненужно, неудобно или неприменимо к вашему фреймворку и C++.
Верно, потому что при этом мы имеем тип возвращаемого значения, которое получим, вызвав метод aquire(). А чтобы узнать, можно ли вообще отправить актору сообщение aquire, что он на него ответит, и должен ли вообще отвечать — нужно лезть либо в документацию к нему, либо в исходный код, что не всегда практически осуществимо. И это сильно понижает производительность труда программиста. Мою, по крайней мере.
Я привел несколько вполне конкретных доводов из моей личной практики в пользу статической типизации акторов. Их дополнил eao197 еще парой примеров. Если вам все еще мало конкретики — то в тех же сферических холиварах "статика vs динамика" их есть еще, и к акторам это тоже вполне применимо.
Более того, есть мнение, что изначальная задумка ООП-подхода основывалась как раз на агентах, которые посылают сообщения друг другу. Но потом что-то пошло не так, и сейчас мы имеем ООП с синхронным дерганьем методов вместо пересылки сообщений. Хотя, попытки реализации объектов на сообщениях были (Objective-C, например).
Да. Как и молоток. Это лишь удобный инструмент, который помогает решить некоторые задачи. Я привык к этому инструменту, он очень плотно вписан в мой рабочий процесс. И его потеря для меня очень ощутима.
Мы топчемся по кругу, вы не находите? Можете прочитать всю ветку комментариев еще раз, все мои доводы там перечислены. На всякий случай обобщу: просто потому что некоторые люди предпочитают типобезопасность другим решениям. Просто потому, что некоторые люди считают, что типобезопасноть решает многие проблемы эффективнее других подходов. Просто потому, что каждый выбирает для себя инструмент, которым лично ему удобнее работать.