- 02 Jun, 2015 1 commit
-
-
Pieter Hintjens authored
Of course people still "can" distributed the sources under the LGPLv3. However we provide COPYING.LESSER with additional grants. Solution: specify these grants in the header of each source file.
-
- 22 Jan, 2015 1 commit
-
-
Pieter Hintjens authored
Solution: update for 2015 Fixes #1320
-
- 02 Jul, 2014 1 commit
-
-
Joel Lauener authored
environment variables.
-
- 02 Jan, 2014 1 commit
-
-
Pieter Hintjens authored
-
- 12 Mar, 2013 1 commit
-
-
Pieter Hintjens authored
Copyrights had become ads for Sustrik's corporate sponsors, going against the original agreement to share copyrights with the community (that agreement was: one line stating iMatix copyright + one reference to AUTHORS file). The proliferation of corporate ads is also unfair to the many individual authors. I've removed ALL corporate title from the source files so the copyright statements can now be centralized in AUTHORS and source files can be properly updated on an annual basis.
-
- 01 Nov, 2011 1 commit
-
-
Martin Sustrik authored
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
-
- 31 Oct, 2011 1 commit
-
-
Martin Sustrik authored
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
-
- 02 Mar, 2011 1 commit
-
-
Martin Sustrik authored
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
-
- 13 Jan, 2011 1 commit
-
-
Martin Sustrik authored
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
-
- 27 Nov, 2010 1 commit
-
-
Martin Sustrik authored
So far these were declared as C++ static functions which was incorrect and caused warnings with SunStudio. Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
-
- 30 Oct, 2010 1 commit
-
-
Martin Sustrik authored
Signed-off-by: Martin Sustrik <sustrik@250bpm.com>
-
- 25 Aug, 2010 1 commit
-
-
Martin Sustrik authored
Sockets may now be migrated between OS threads; sockets may not be used by more than one thread at any time. To migrate a socket to another thread the caller must ensure that a full memory barrier is called before using the socket from the target thread. The new zmq_close() semantics implement the behaviour discussed at: http://lists.zeromq.org/pipermail/zeromq-dev/2010-July/004244.html Specifically, zmq_close() is now deterministic and while it still returns immediately, it does not discard any data that may still be queued for sending. Further, zmq_term() will now block until all outstanding data has been sent. TODO: Many bugs have been introduced, needs testing. Further, SO_LINGER or an equivalent mechanism (possibly a configurable timeout to zmq_term()) needs to be implemented.
-
- 05 Jan, 2010 1 commit
-
-
Martin Sustrik authored
-
- 29 Aug, 2009 1 commit
-
-
Martin Sustrik authored
-
- 03 Aug, 2009 1 commit
-
-
Martin Sustrik authored
-
- 29 Jul, 2009 1 commit
-
-
Martin Sustrik authored
-