- 27 May, 2018 1 commit
-
-
Simon Giesecke authored
Problem: inconsistent naming style for private data members, conflicts with naming of local variables and member functions Solution: apply and check _lower_case naming style for private data members
-
- 24 May, 2018 1 commit
-
-
Simon Giesecke authored
Solution: make allocator a member of decoder_base_t
-
- 05 Mar, 2018 1 commit
-
-
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.
-
- 02 Feb, 2018 1 commit
-
-
sigiesec authored
Solution: applied clang-format
-
- 28 Jan, 2016 1 commit
-
-
Constantin Rack authored
Solution: update to 2016
-
- 05 Jul, 2015 1 commit
-
-
Jens Auer authored
A memcpy is eliminated when receiving data on a ZMQ_STREAM socket. Instead of receiving into a static buffer and then copying the data into the buffer malloced in msg_t::init_size, the raw_decoder allocates the memory for together with the reference-counter and creates a msg_t object on top of that memory. This saves the memcpy operation. For small messages, data is still copied and the receive buffer is reused.
-
- 14 Jun, 2015 3 commits
-
-
Jens Auer authored
-
Jens Auer authored
The shared reference count was not shared but copied. msg_t cannot store the refcnt itsef but has to store a pointer to an externally allocated (shared) refcnter. The changes to lmsg are reverted to use content_t again. Howver, this introduces an allocation in v2_decoder when creating the message which can be avoided. When allocating the reception buffer, space is allocated for the maximum number of reference counts (8192 / max_vsm_size = 8192/64 = 128 zmq:atomic_counter objects). This increases the buffer by 128*sizeof(atomic_counter) = 128*4 = 512 bytes only. When creating a message, the refcnt member is set to the address of one of the pre-allocated atomic_counter_t objects. To do so, a new msg_t type zcmsg is introduced because msg::copy must discriminate between the message types when releasing memory.
-
Jens Auer authored
zero-copy msg_t::init cannot be used when the message exceeds either the buffer end or the last received byte. To detect this, the buffer is now resized to the numnber of received bytes.
-
- 03 Jun, 2015 1 commit
-
-
Jens Auer authored
Construct messages from a reference-counted buffer allocated once per receive instead of copying the data.
-
- 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 Jan, 2014 1 commit
-
-
Pieter Hintjens authored
-
- 11 Apr, 2013 1 commit
-
-
Martin Hurton authored
-
- 12 Mar, 2013 2 commits
-
-
Pieter Hintjens authored
-
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.
-
- 13 Nov, 2012 1 commit
-
-
Martin Hurton authored
-
- 05 Sep, 2012 1 commit
-
-
Martin Hurton authored
This is supposed to become part of the ZMTP/1.1. The main differences from the ZMTP/1.0 framing protocol are: - flags field comes first, followed by the length field - long messages are signaled using a flag rather then 0xff escape - length field does not include the flags field, 0 is a valid value
-