1. 06 Mar, 2017 1 commit
  2. 03 Mar, 2017 1 commit
  3. 26 Dec, 2016 2 commits
  4. 05 Dec, 2016 1 commit
    • Luca Boccassi's avatar
      Problem: 4.2.0 won't compile on AIX 7.1 · 57db5f2a
      Luca Boccassi authored
      Solution: restore inclusion of poll.h if using poll before zmq.h as
      it was originally, as AIX redefines the POSIX structures and provides
      compatibility macros.
      Also add alternative aliases for 32 bit AIX's pollitem struct:
        events -> reqevents
        revents -> rtnevents
      57db5f2a
  5. 17 Sep, 2016 1 commit
  6. 11 Jun, 2016 1 commit
    • Michael Lutz's avatar
      Problem: Windows performance is not optimal due to select(). · 7a6ff07a
      Michael Lutz authored
      Solution: Provide poll() for Windows as well. This is a build option that
      defaults to off as the resulting binary will only run on Windows Vista or
      newer.
      
      This is not tested with alternative Winsock service providers like VMCI,
      but the documentation for WSAPoll does not mention limitations.
      
      On my local machine, throughput improves by ~10 % (20 simultaneous
      remote_thr workes to one local_thr, 10 byte messages), while latency
      improves by ~30 % (measured with remote/local_lat).
      7a6ff07a
  7. 14 May, 2016 1 commit
  8. 26 Apr, 2016 1 commit
  9. 21 Feb, 2016 2 commits
  10. 18 Feb, 2016 1 commit
  11. 28 Jan, 2016 1 commit
  12. 01 Nov, 2015 1 commit
    • Pieter Hintjens's avatar
      Problem: Windows 7 TCP slow start · 54e2e2a7
      Pieter Hintjens authored
      See issue #1608.
      
      This is an old issue with Windows 7. The effect is that we see a latency
      ramp on the first 500 messages.
      
      * The ramp is unaffected by message size.
      * Sleeping up to 100msec between sends has no effect except to switch
          off ZeroMQ batching so making the ramp more visible.
      * After 500 messages, latency falls back down to ~10-40 usec.
      * Over inproc:// the ramp happens when we use the signaler class.
      * Client-server over inproc:// does not show the ramp.
      * Client-server over tcp:// shows a similar ramp.
      
      We know that the signaller is using TCP on Windows. We can 'prime' the
      connection by doing 500 dummy sends. This potentially causes new sockets
      to be delayed on creation, which is not a good solution.
      
      Note that the signaller sends zero-byte messages. This may also be
      confusing TCP.
      
      Solution: flood the receive buffer when creating a new FD pair; send a
      1M buffer and discard it.
      
      Fixes #1608
      54e2e2a7
  13. 30 Oct, 2015 1 commit
  14. 29 Sep, 2015 1 commit
    • KIU Shueng Chuan's avatar
      create signaler::recv_failable() · 596d6e5b
      KIU Shueng Chuan authored
      In real world usage, there have been reported signaler failures where the
      eventfd read() or socket recv() system call in signaler::recv() fails,
      despite having made a prior successful signaler::wait() call.
      
      this patch creates a signaler::recv_failable() method that allows
      unreadable eventfd / socket to return an error without asserting.
      596d6e5b
  15. 18 Sep, 2015 1 commit
  16. 06 Sep, 2015 1 commit
  17. 03 Sep, 2015 1 commit
  18. 02 Sep, 2015 1 commit
  19. 28 Jul, 2015 1 commit
  20. 23 Jul, 2015 1 commit
  21. 22 Jul, 2015 2 commits
  22. 02 Jun, 2015 1 commit
  23. 20 Apr, 2015 1 commit
  24. 22 Jan, 2015 1 commit
  25. 24 Sep, 2014 1 commit
  26. 23 Jul, 2014 1 commit
    • Ewen McNeill's avatar
      z/OS: Loop on EAGAIN on close() in ~signaler · 0af693c4
      Ewen McNeill authored
      Updated:
          src/signaler.cpp: Add close_wait_ms() static function to loop
             when receiving EAGAIN in response to close(), with ms long
             sleeps, up to a maximum limit (default 2000ms == 2 seconds);
             used in signaler_t::~signaler_t() destructor.
      0af693c4
  27. 09 Jul, 2014 1 commit
  28. 28 Apr, 2014 1 commit
  29. 27 Apr, 2014 1 commit
  30. 25 Apr, 2014 1 commit
  31. 30 Mar, 2014 1 commit
  32. 18 Mar, 2014 1 commit
  33. 17 Feb, 2014 1 commit
    • Olaf Mandel's avatar
      Remove duplicate poller decision making · 48b50cef
      Olaf Mandel authored
      The decision about the poller mechanism to use (select, poll, ...)
      was done twice: once by the build system and once by the code in
      poller.hpp. As the build-system can actually detect the mechanisms
      available, prefer that result to the hard coded defaults in
      poller.hpp.
      
      At the same time, remove the duplicate detection of select() vs.
      poll()-variant from proxy.cpp, signaler.cpp and zmq.cpp.
      
      This patch has not been tested on many build platforms: especially
      the cmake build needs testing / patching. For the other builds,
      hard code the result as these these are all Windows platforms.
      48b50cef
  34. 02 Jan, 2014 1 commit
  35. 11 Dec, 2013 1 commit
  36. 28 Nov, 2013 1 commit
  37. 11 Nov, 2013 1 commit