1. 18 May, 2018 1 commit
  2. 14 May, 2018 1 commit
  3. 10 Mar, 2018 1 commit
    • Manuel Segura's avatar
      Pull request to merge porting to WindRiver VxWorks 6.x (#2966) · 4726f726
      Manuel Segura authored
      * Problem: Still need to port over more files to VxWorks 6.x
      
      Solution: Port more files to VxWorks 6.x
      
      * Problem: Need to port over remaining files to VxWorks 6.x. Also remove POSIX thread dependency for VxWorks (because of priority inversion problem in POSIX mutexes with VxWorks 6.x processes)
      
      Solution: Port over remaining files to VxWorks 6.x. Also removed POSIX thread dependency for VxWorks
      
      * Problem: Needed to modify TCP, UDP, TIPC classes with #ifdefs to be compatible with VxWorks 6.x.
      
      Solution:  Modify TCP, UDP, TIPC classes with #ifdefs to be compatible with VxWorks 6.x
      4726f726
  4. 13 Feb, 2018 1 commit
    • Simon Giesecke's avatar
      Problem: network initialization and shutdown functions not available for · e8e24030
      Simon Giesecke authored
      reuse
      
      Solution: extract into functions defined in ip.hpp
      
      Problem: signaler_t::make_fdpair not reusable
      
      Solution: move make_fdpair to ip.hpp
      
      Problem: epoll worker with no fds cannot be stopped
      
      Solution: use interruptible epoll_pwait call
      
      Problem: insufficient unit tests for poller
      
      Solution: add test cases
      e8e24030
  5. 09 Feb, 2018 2 commits
  6. 08 Feb, 2018 1 commit
  7. 02 Feb, 2018 1 commit
  8. 31 Jan, 2018 1 commit
  9. 04 Apr, 2017 1 commit
    • bbdb68's avatar
      Problem: no windows UWP support · 1d58a009
      bbdb68 authored
      * add define for windows/UWP
      
      * prevent issue with COM references
      
      * gettickcount not available on uwp
      
      * add compiler definitions
      
      * add convenitnece cmake file
      
      * brute force uwp compilation
      
      * fix compiler version
      
      * cosmetics
      1d58a009
  10. 27 Mar, 2017 1 commit
  11. 06 Mar, 2017 1 commit
  12. 03 Mar, 2017 1 commit
  13. 26 Dec, 2016 2 commits
  14. 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
  15. 17 Sep, 2016 1 commit
  16. 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
  17. 14 May, 2016 1 commit
  18. 26 Apr, 2016 1 commit
  19. 21 Feb, 2016 2 commits
  20. 18 Feb, 2016 1 commit
  21. 28 Jan, 2016 1 commit
  22. 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
  23. 30 Oct, 2015 1 commit
  24. 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
  25. 18 Sep, 2015 1 commit
  26. 06 Sep, 2015 1 commit
  27. 03 Sep, 2015 1 commit
  28. 02 Sep, 2015 1 commit
  29. 28 Jul, 2015 1 commit
  30. 23 Jul, 2015 1 commit
  31. 22 Jul, 2015 2 commits
  32. 02 Jun, 2015 1 commit
  33. 20 Apr, 2015 1 commit
  34. 22 Jan, 2015 1 commit
  35. 24 Sep, 2014 1 commit
  36. 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