Skip to content
Snippets Groups Projects
  1. Feb 12, 2016
    • George Joseph's avatar
      res_pjsip: Refactor load_module/unload_module · b37555cc
      George Joseph authored
      load_module was just too hairy with every step having to clean up all
      previous steps on failure.
      
      Some of the pjproject init calls have now been moved to a separate
      load_pjsip function and the unload_pjsip function was enhanced to clean
      up everything if an error happened at any stage of the load process.
      
      In the process, a bunch of missing pj_shutdowns, serializer_pool_shutdowns
      and ast_threadpool_shutdowns were also corrected.
      
      Change-Id: I5eec711b437c35b56605ed99537ebbb30463b302
      b37555cc
  2. Feb 11, 2016
  3. Feb 10, 2016
  4. Feb 09, 2016
    • Corey Farrell's avatar
      Simplify and fix conditional in FD_SET. · 68643f83
      Corey Farrell authored
      FD_SET contains a conditional statement to protect against buffer
      overruns.  The statement was overly complicated and prevented use
      of the last array element of ast_fdset.  We now just verify the fd
      is less than ast_FDMAX.
      
      Change-Id: I41895c0b497b052aef5bf49d75c817c48b326f40
      68643f83
    • Joshua Colp's avatar
    • Joshua Colp's avatar
      tests/test_sorcery_memory_cache_thrash: Improve termination process. · e40fddbe
      Joshua Colp authored
      When terminating the threads thrashing a sorcery memory cache each
      would be told to stop and then we would wait on them. During at
      least one thrashing test this was problematic due to the specific
      usage pattern in use. It would take some time for termination of the
      thread to occur.
      
      This would occur due to contention between the threads retrieving
      and the threads updating the cache. As the retrieving threads are
      given priority it may be some time before the updating threads
      are able to proceed.
      
      This change makes it so all threads are told to stop and then each
      are joined to ensure they stop. This way all the threads should
      stop at around the same time instead of waiting for one to stop,
      the next to stop, then the next, and so on. As a result of this
      the execution time for each thrash test is much closer to their
      expected value than previously seen as well.
      
      Change-Id: I04a53470b0ea4170b8819180b0bd7475f3642827
      e40fddbe
    • George Joseph's avatar
      res_pjsip: Fix infinite recursion when loading transports from realtime · bbf3ace6
      George Joseph authored
      Attempting to load a transport from realtime was forcing asterisk into an
      infinite recursion loop.  The first thing transport_apply did was to do a
      sorcery retrieve by id for an existing transport of the same name. For files,
      this just returns the previous object from res_sorcery_config's internal
      container, if any.  For realtime, the res_sourcery_realtime driver looks in the
      database and finds the existing row but now it has to rehydrate it into a
      sorcery object which means calling... transport_apply.  And so it goes.
      
      The main issue with loading from realtime (apart from the loop) was that
      transport stores structures and pointers directly in the ast_sip_transport
      structure instead of the separate ast_transport_state structure.  This patch
      separates those items into the ast_sip_transport_state structure.  The pattern
      is roughly the same as res_pjsip_outbound_registration.
      
      Although all current usages of ast_sip_transport and ast_sip_transport_state
      were modified to use the new ast_sip_get_transport_state API, the original
      items are left in ast_sip_transport and kept updated to maintain ABI
      compatability for third-party modules.  They are marked as deprecated and
      noted that they're now in ast_sip_transport_state.
      
      ASTERISK-25606 #close
      Reported-by: Martin Moučka
      
      Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19
      bbf3ace6
  5. Feb 08, 2016
  6. Feb 07, 2016
  7. Feb 05, 2016
  8. Feb 04, 2016
  9. Feb 03, 2016
Loading