На главную Наши проекты:
Журнал   ·   Discuz!ML   ·   Wiki   ·   DRKB   ·   Помощь проекту
ПРАВИЛА FAQ Помощь Участники Календарь Избранное RSS
msm.ru
Модераторы: Qraizer, Hsilgos
Страницы: (4) « Первая ... 2 3 [4]  все  ( Перейти к последнему сообщению )  
> Трабла с манипулятором , Вызывается не то и не там :(
    Wound, киля, да да да, ты прав!
    Пока осознанного решения для вызовов а-ля "<< ололо << ололо << ололо << ололо" без гонки я не вижу.
    Тут вопрос принципиальный, как распознать "конец цепочки вызовов".
    У меня такого решения пока нет :-?
      Цитата JoeUser @
      В пока осознанного решения для вызовов а-ля "<< ололо << ололо << ололо << ололо" без гонки я не вижу.

      Ну одно ты забраковал, то, которое я привел с манипулятором, без вызова которого - все уйдет в режим ожидания.
      Второе привел Oleg M
      Я его даже уже реализовал. Идея в том, что в каждом потоке ты пишешь в локальный поток, который возвращает логгер, а потом скидываешь все в этот самый логгер.
      Второе решение кажется мне более красивым, чем мое. Но я свое делал, потому что обиделся на манипулятор :D Уже ради принципе там извращался.

      Цитата JoeUser @
      Тут вопрос принципиальный, как распознать "конец цепочки вызовов".
      У меня такого решения пока нет

      Вот как вариант - с помощью conditional_variable, но тогда без вызова flush, все заблокируется.
      Либо писать в локальную переменную Ну или как Qraizer предлагал, либо смотри мой первый пост.
      Смысл в том, чтобы блокировать всю цепочку вызовов - operator << и писать ее во временную переменную, а уж потом ее возвращать.
      Сообщение отредактировано: Wound -
        Цитата Wound @
        Ну или как Qraizer предлагал, либо смотри мой первый пост.
        Qraizer вообще-то твой исходный код, без смены архитектуры, подправил уже давно.
          Wound, не не не.
          Вопрос в другом!
          Который можно обозначить так: "Как обозначить цепочку вызовов записи в стрим - как законченную 'транзакцию'?"

          Лично я пока вижу один выход - собирать как-то "сообщение" из всех "<<" воедино и отдавать одним вызовом.
          На большее - креативу не хватает :'(
            Цитата Qraizer @
            Qraizer вообще-то твой исходный код, без смены архитектуры, подправил уже давно.

            Да, я знаю, я видел. Но ведь не удобно писать Guard(logger) << message.
              Цитата Wound @
              Да, я знаю, я видел. Но ведь не удобно писать Guard(logger) << message.

              Сорри, убегаю и не осознал ... но чисто вопрос.

              В случае Guard(logger) << message1 << message2 << message3

              Есть ли механизмы предотвращения гонки? И если "да" - это где?
                Цитата JoeUser @
                Есть ли механизмы предотвращения гонки? И если "да" - это где?

                Да, там есть такой механизм, вот Qraizer его описал:
                Цитата Qraizer @
                Ну да, перемудрил, пожалуй. Тебе было надо лишь залочить логгер до конца выражения. Для этого достаточно временного Guard, лочащего агрегированный в логгер std::basic_ostream, и отпускающего его в деструкторе, а сами << пусть бы работали сами по себе, стандартные. И не надо было бы никаких враперов.

                Просто в моем первом варианте нужно выкинуть WrappedStream, и писать примерно так:
                ExpandedWrap disabled
                  GuardStream(std::cout) << message1 << message2 << std::endl;

                Только там у GuardStream нужно operator << перегрузить. Получится что у тебя в момент вызова GuardStream(std::cout) создается локальный временный объект GuardStream, который в конструкторе лочит std::cout, а в деструкторе отпускает его и вызывает flush.
                Ну или готовое решение смотри по ссылке, что привел Qraizer: Маразм программёров
                Сообщение отредактировано: Wound -
                  Цитата Wound @
                  Да, я знаю, я видел. Но ведь не удобно писать Guard(logger) << message.
                  Нет, ты не увидел.

                  Добавлено
                  Ты просил реализацию манипулятора, я предложил сменить архитектуру. и не только я. Возможно, так и следует поступить, но конкретно твой вопрос по манипулятору решён.

                  Добавлено
                  https://ideone.com/0j423Q
                    Цитата Qraizer @
                    Нет, ты не увидел.

                    Да, действительно. Я сообщение только то прочитал, а сам код что ты приложил не анализировал, видимо из за того, что на тот момент я сутки не спал.

                    Цитата Qraizer @
                    Ты просил реализацию манипулятора, я предложил сменить архитектуру. и не только я.

                    Я тоже предлагал сменить архитектуру.
                    Цитата Wound @
                    Передал ему ссылку на Logger, в итоге выхватил исключение при попытке залочить мьютекс. Может быть тут можно как то дизайн пересмотреть, а то у меня голова уже не варит, с 3 ночи сижу пытаюсь этот манипулятор написать. Мне кажется я уже все варианты перепробовал.




                    Цитата Qraizer @
                    но конкретно твой вопрос по манипулятору решён.

                    Добавлено 9 минут назад
                    https://ideone.com/0j423Q

                    К слову я так же переписывал, но ловил исключение на повторном захвате мьютекса. Видимо как раз там и нужно было изменить на рекурсивный мьютекс. На тот момент, как то не подумал об этом, хотя мысля была об этом.
                    Сообщение отредактировано: Wound -
                      Цитата Wound @
                      Видимо как раз там и нужно было изменить на рекурсивный мьютекс.
                      Вообще говоря, если используешь std для лочки расшаренных ресурсов, имеет смысл всегда использовать именно их, т.к. точно соответствуют критическим секциям по назначению. Обычные мьютексы соответствуют виндовым семафорам со счётчиком 2, что требуются гораздо реже.
                      0 пользователей читают эту тему (0 гостей и 0 скрытых пользователей)
                      0 пользователей:


                      Рейтинг@Mail.ru
                      [ Script execution time: 0,0350 ]   [ 16 queries used ]   [ Generated: 28.03.24, 13:06 GMT ]