1. 17 Apr, 2020 1 commit
    • Doron Somech's avatar
      problem: ZMQ_HEARTBEAT is not useful without sending an hello message · 93da6763
      Doron Somech authored
      When using ZMQ_HEARTBEAT one still needs to implement application-level heartbeat in order to know when to send a hello message.
      For example, with the majordomo protocol, the worker needs to send a READY message when connecting to a broker. If the connection to the broker drops, and the heartbeat recognizes it the worker won't know about it and won't send the READY msg.
      To solve that, the majordomo worker still has to implement heartbeat. With this new option, whenever the connection drops and reconnects the hello message will be sent, greatly simplify the majordomo protocol, as now READY and HEARTBEAT can be handled by zeromq.
      93da6763
  2. 27 Jan, 2020 3 commits
  3. 26 Jan, 2020 1 commit
  4. 25 Dec, 2019 1 commit
  5. 08 Dec, 2019 2 commits
  6. 02 Oct, 2019 1 commit
  7. 11 Sep, 2019 1 commit
  8. 27 Aug, 2019 1 commit
  9. 21 May, 2019 1 commit
  10. 17 Feb, 2019 3 commits
  11. 15 Jan, 2019 1 commit
  12. 18 Nov, 2018 1 commit
  13. 15 Aug, 2018 2 commits
  14. 09 Aug, 2018 1 commit
  15. 07 Aug, 2018 1 commit
  16. 28 May, 2018 2 commits
  17. 27 May, 2018 1 commit
  18. 26 May, 2018 2 commits
  19. 18 May, 2018 1 commit
  20. 13 May, 2018 1 commit
  21. 05 Mar, 2018 1 commit
    • Stefan Kaes's avatar
      Problem: enormous memory increase due to zero copy decoding · fcbd2a57
      Stefan Kaes authored
      The zero copy decoding strategy implemented for 4.2.0 can lead to a large
      increase of main memory usage in some cases (I have seen one program go up to
      40G from 10G after upgrading from 4.1.4). This commit adds a new option to
      contexts, called ZMQ_ZERO_COPY_RECV, which allows one to switch to the old
      decoding strategy.
      fcbd2a57
  22. 11 Feb, 2018 1 commit
  23. 02 Feb, 2018 1 commit
  24. 31 Jan, 2018 1 commit
  25. 25 Oct, 2017 1 commit
    • f18m's avatar
      Change ZMQ_THREAD_AFFINITY to… · 2aa0e6fd
      f18m authored
      Change ZMQ_THREAD_AFFINITY to ZMQ_THREAD_AFFINITY_CPU_ADD/ZMQ_THREAD_AFFINITY_CPU_REMOVE. Avoid prefix thread names when no prefix was set.
      2aa0e6fd
  26. 22 Oct, 2017 1 commit
  27. 17 Oct, 2017 1 commit
  28. 16 Oct, 2017 1 commit
    • f18m's avatar
      Background threads enhancements (#2778) · bfbb4ff2
      f18m authored
      * Background thread scheduling 
      
      - add ZMQ_THREAD_AFFINITY ctx option; set all thread scheduling options
      from the context of the secondary thread instead of using the main
      process thread context!
      - change ZMQ_THREAD_PRIORITY to support setting NICE of the background
      thread when using SCHED_OTHER
      bfbb4ff2
  29. 19 Sep, 2017 1 commit
  30. 07 Sep, 2017 1 commit
  31. 06 Sep, 2017 1 commit
  32. 28 Jul, 2017 1 commit
    • Luca Boccassi's avatar
      Problem: fd leak in tweetnacl with one ctx per thread · e015a0f8
      Luca Boccassi authored
      Solution: add a crypto [de-]initialiser, refcounted and serialised
      through critical sections.
      This is necessary as utility APIs such as zmq_curve_keypair also
      call into the sodium/tweetnacl libraries and need the initialisation
      outside of the zmq context.
      Also the libsodium documentation explicitly says that sodium_init
      must not be called concurrently from multiple threads, which could
      have happened until now. Also the randombytes_close function does
      not appear to be thread safe either.
      This change guarantees that the library is initialised only once at
      any given time across the whole program.
      Fixes #2632
      e015a0f8