1. Си / Говнокод #11581

    +106

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    if ( ... )
      {
        if ( ... )
          {
            if ( ... )
              {
                usleep(250000);
              }
            else
              {
                sleep( 1 );
              }
          }
        else
          {
            if ( ... )
              {
                if ( ... )
                  {
                    usleep( 250000 );
                  }
                else
                  {
                    sleep( ... );
                  }
              }
            else
              {
                sleep( ... );
              }
          }
      }
    else
      {
        usleep( 250000 );
      }

    из главного цикла одного "рил-тайм" приложения. (комментарии, етц были удалены.)

    каждый раз тестеры/кастомеры жалуются что приложение работает слишком медленно или слишком быстро - появляется либо новый if со слипом, либо новый else со слипом. за два года существования, вот до этого "полного" дерева доросло. и все равно не работает как надо. :)

    Запостил: Dummy00001, 13 Августа 2012

    Комментарии (6) RSS

    • Пишем подушку? :)
      Ответить
    • слишком быстро - это когда должно условно тикать каждую секунду, но тикает каждые 800мс?
      Ответить
      • :)

        это из приложения скедулера. в ин-мемори базе лежит куча информации с таймстемпами (почти таймеры). эта апликуха по этой информации триггеры "сделай то/сделай это" другим приложениям через миддлваре высылает. "слишком быстро" это когда она за пару минут несколько миллионов тригеров успевает выслать, что вся остальная система пол часа только и делает что обрабатывает эти сообщения тригеры. (случает как правило тогда когда прикладуху выключали на пару дней и действий в памяти накопилось.)
        Ответить
        • действительно ли необходимо ставить это всё в очередь офлайновой подсистеме?
          просто обычно если и надо ставить, то только важные данные, которые нельзя потерять, и которые при восстановлении подсистемы обязаны быть переработаны - тогда чем быстрее, тем лучше, хоть она и будет перемалывать их полчаса (полдня)
          Ответить
          • Может в очередь и стоит ставить, только не помешает дублирующие сообщения из очереди убирать. Или просто не обрабатывать их, если обработка уже в процессе.
            Ответить
          • > действительно ли необходимо ставить это всё в очередь офлайновой подсистеме?

            в некоторых случаях - да.

            тут еще грабли в том что это, да, писалось для офф-лайн системы - но сегодня используется исключительно в он-лайн исталяциях.

            там скорее всего вся концепция говно. почему наверное конкуренты подобной функциональности и не предлагают. (что нашему маркетингу как котам валерьянка.)
            Ответить

    Добавить комментарий