In reading through '36/ZeroMQ Realtime Exchange Protocol' there looks to be
a typo in -
When a ZRE node receives a beacon from a node that it does not already
know about, with a non-zero port number, it SHALL consider this to be a new
peer.
When a ZRE node receives a beacon from a known node,
FWIW I've release aziomq which integrates boost::asio and ZeroMQ.
It's still early in development, but among the doc samples is code that
sets up signal handlers on the asio io_service
see -
https://github.com/aziomq/aziomq4-x
On Fri, May 23, 2014 at 4:53 AM, Bjorn Reese
zmq_socket_monitor?
http://api.zeromq.org/4-0:zmq-socket-monitor
On Fri, May 30, 2014 at 9:21 AM, Jeremy Richemont jrichem...@gmail.com
wrote:
Thanks, Charles. I did, in fact, find that pattern. The problem is it does
not match what I am trying to do. That pattern for when you have state +
set_sockopt accepts arguments by void* and casts them, later to int* iif
sizeof(int) == optvalen. There's no proper narrowing conversion, and no
compiler warning.
On Mon, Jun 16, 2014 at 12:36 PM, Gerry Steele gerry.ste...@gmail.com
wrote:
Hi Pieter, you have struck on something there.
GCC4.7(x86_64) - sizeof(int) = 4, sizeof(uint64_t) = 8
On Mon, Jun 16, 2014 at 1:03 PM, Pieter Hintjens p...@imatix.com wrote:
Hmm, it does check the size of the passed argument, and if that's
wrong, returns an error (which you do check for).
On Mon, Jun 16, 2014 at 7:36 PM, Gerry Steele
If so, debug/checked builds only please.
On Mon, Jun 16, 2014 at 5:11 PM, Pieter Hintjens p...@imatix.com wrote:
Indeed... I've had this hit more than once, a zmq_setsockopt that
caused an error that wasn't being handled, with weird and expensive
results down the line.
Kind of makes you
Just curious what the rationale for this is? The result of least
astonishment (to me anyway) would be a copy of an empty message.
zmq_msg_t a;
zmq_msg_init(a);
...
zmq_msg_t b;
int rc = zmq_msg_copy(b, a);
assert(rc == 0); // fails, errno=EINVAL
___
and get it to
work as you'd expect.
On Wed, Jul 2, 2014 at 8:22 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Just curious what the rationale for this is? The result of least
astonishment (to me anyway) would be a copy of an empty message.
zmq_msg_t a;
zmq_msg_init
it's value to 0 (no effect on non-shared messages).
So the only API surface area change is an additional message property.
This seems the cleanest to me.
On Wednesday, July 9, 2014, Goswin von Brederlow goswin-...@web.de wrote:
On Tue, Jul 08, 2014 at 10:42:41AM -0500, Thomas Rodgers wrote:
tl
after you have obtained its value?
E.g.
Make a copy
Send the 1st
Read the refcount (2)
Background io releases 1st copy
On 9 Jul 2014 18:21, Thomas Rodgers rodg...@twrodgers.com wrote:
zmq_msg_get() could be extended to give either the refcount or an
indicator on whether a message was share
, Pieter Hintjens p...@imatix.com wrote:
It sounds like a valid problem, and the simplest answer seems to be a
zmq_msg_get() constant.
On Wed, Jul 9, 2014 at 12:21 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
zmq_msg_get() could be extended to give either the refcount or an
indicator
:
It sounds like a valid problem, and the simplest answer seems to be a
zmq_msg_get() constant.
On Wed, Jul 9, 2014 at 12:21 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
zmq_msg_get() could be extended to give either the refcount or an
indicator
on whether a message was share; based on other
I'm on my annual road trip, so it will be few days still before I have time
to put the patch together.
On Friday, July 11, 2014, Goswin von Brederlow goswin-...@web.de wrote:
On Wed, Jul 09, 2014 at 04:53:16PM -0500, Thomas Rodgers wrote:
Right. This is my trepidation about surfacing
Pull request submitted.
On Fri, Jul 11, 2014 at 7:43 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
I'm on my annual road trip, so it will be few days still before I have
time to put the patch together.
On Friday, July 11, 2014, Goswin von Brederlow goswin-...@web.de wrote:
On Wed, Jul
The difficulty may come in dealing with late message arrivals but that can
probably just be pushed onto the user to detect and handle.
Would that be the lesser of the 'evils' in question here? To me, throwing
away the socket on a hard failure (e.g. timeout of the remote endpoint)
makes a
Pull req submitted.
Thanks,
Tom.
On Tue, Jul 29, 2014 at 1:06 PM, Pieter Hintjens p...@imatix.com wrote:
Since it's a single semantic (you do not own this message) one name is
better.
On Tue, Jul 29, 2014 at 4:30 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Reopening this -
I
1) I want to use CURVE and zmq_msg_gets()
When I recv() a message on the ROUTER socket it has metadata attached
to it. Can I (and how) forward this message across the PAIR socket savely
keeping the metadata pointer intact so the app can still call
zmq_msg_gets() on it?
caveat; I haven't
What exactly would an application do in the face of exhausting file
descriptors to recover? I have encountered numerous cases with the JVM
where it's notion of finalization is decidedly too lazy to be of practical
use (memory mapped files/regions for instance). I've also encountered
several
On Tue, Aug 12, 2014 at 4:42 PM, Michi Henning mi...@triodia.com wrote:
Yet I'll repeat my assertion that if an
application or binding is incompetent enough to pass garbage
arguments, then it cannot be competent enough to check errors
properly.
That seems a bit too simplistic to me.
going down some poorly tested code path tickled only under highly
unusual circumstances.
On Tue, Aug 12, 2014 at 4:49 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
On Tue, Aug 12, 2014 at 4:42 PM, Michi Henning mi...@triodia.com wrote:
Yet I'll repeat my assertion
I agree with you in the sense that, specifically speaking about 0mq,
errors that can be checked synchronously (you called the function, and
the check happens then) should return sensible error codes that
binding authors should be responsible for checking and throwing (or
whatever) their
At least for languages that support exceptions, I believe throwing an
exception for invalid arguments is far preferable to just killing the
process.
I write a lot of C++ code for automated trading systems, so I come at this
from the view that there is no way in this world to light yourself
The recently landed pull request #1161
https://github.com/zeromq/libzmq/pull/1161 would now seem to preclude
forwarding on metadata to a PAIR socket.
On Mon, Aug 11, 2014 at 11:23 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
1) I want to use CURVE and zmq_msg_gets()
When I recv
on them, and the vast lack of counter-data grow and grow.
You get more reliable software by eliminating those strange unexpected
code paths, not by adding error handling into the mix.
-Pieter
On Wed, Aug 13, 2014 at 2:08 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
At least for languages
Horrid C API design by individuals who felt C++ was the superior
language and that POSIX socket API compatibility was more important
than usability.
I'm not sure what C++ has to do with any of this. It is certainly not
idiomatic 'modern' C++ to have raw void* or any raw resource owning
pointers
If the message size exceeds the 'vsm' message length limit, it becomes an
'lmsg'. This type is indeed heap allocated, and when the enclosing message
type is copied, the copies share the reference to the underlying heap
allocation (and any potential data races that come along with that). The
H, I just ran this on my *nix box (Ubuntu 14.04, gcc4.8) with helgrind
and I get no races in zmq::msg_t::close() reported, nor do I see anything
in the implementation of zmq::msg_t::close() that's likely racey in
practice.
On Monday, August 18, 2014, Michi Henning mi...@triodia.com wrote:
stack smashing detector, so seems like a 4.1 specific issue mebe?
If I get some time tomorrow, I will try to figure out why (no obvious from
a libzmq call in the backtrace).
On Mon, Aug 18, 2014 at 9:53 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
H, I just ran this on my *nix box (Ubuntu
:03 AM, Michi Henning mi...@triodia.com wrote:
On 19/08/14 13:28, Thomas Rodgers wrote:
... then, having realizing that it linked against the Ubuntu installed
default version (libzmq3), I re-ran this against libzmq4 and the current
libzmq 'trunk'. I get no races/issues in libzmq3 or libzmq4
use the appropriate socket type (eg PAIR) connected over the 'inproc://'
transport to replace your queues, DO NOT share sockets between threads
(context is ok). With PAIR you also have to arrange to call bind() before
the other thread calls connect().
On Thu, Aug 21, 2014 at 7:28 AM, Raju
uuid's are 16 octets long, so you can just use char[16] as the datatype for
it. If you are happen to be using boost, it's uuid type has a data which
is defined that way.
On Tue, Aug 26, 2014 at 8:29 AM, Riskybiz riskybizl...@live.com wrote:
Is it these lines which are the problem with c_str()
FWIW, Erlang's gen_server behavior supports a call() form which takes a
timeout (by default infinity). If the call times out, the call fails with
an exception, unless you catch this (not the usual Erlang way) the process
initiating the call will terminate, propagating the failure to any other
In practice, Erlang apps are more than the base actor machinery and
messaging. Erlang has a notion of 'linked processes' where a fault in a
linked process is reliably propagated to all linking processes. On top of
this they build a rich set of fault tolerant behaviors in OTP, one of
which, the
How do you display the string on the receiving end?
On Sunday, September 14, 2014, Dávid Kaya m...@davidkaya.sk wrote:
Hi,
Let's say I have a message like this one:
string loginMessage = login;
zmq::message_t
request((void*)loginMessage.c_str(),loginMessage.length(),NULL);
whenever I
When you create a message via zmq_init_data() (which zmq::message_t does
with the constructor args you specified, and specify NULL for the ffn
argument, it becomes a const message, which means that ZeroMQ assumes
ownership of the pointer you handed it (it's a cmsg type, e.g. *const*
data). It
Message goes out of scope, destructor called, receiving side is getting a
pointer to a free'd heap block.
On Mon, Sep 15, 2014 at 10:27 AM, Dávid Kaya m...@davidkaya.sk wrote:
Here is that function: http://pastebin.com/AgUuDqqK .
On 15.09.2014 19:19, gonzalo diethelm wrote:
Without seeing
am done with the
socket, right? Or should I have (message_t*) for every message I use?
On 15.09.2014 19:30, Thomas Rodgers wrote:
Message goes out of scope, destructor called, receiving side is
getting a pointer to a free'd heap block.
On Mon, Sep 15, 2014 at 10:27 AM, Dávid Kaya wrote
You will need cast ackMessage.data() to char* (e.g.
static_castchar*(ackMessage.data())) for that to work.
On Mon, Sep 15, 2014 at 10:52 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
You can do something like -
zmq::message_t ackMessage(message.size());
std::copy_n(message.data
Sigh, no good deed goes unpunished...
To your original question -
As covered in the zguide, ZeroMQ is already managing a background thread on
your behalf that is 'pumping' the underlying transport's socket and pulling
messages/sending messages as fast as it can (using epoll, select, IOCP,
etc.
Any update on a fix?
On Tue, Oct 14, 2014 at 9:33 AM, Pieter Hintjens p...@imatix.com wrote:
There are still some formatting issues. These pages are built by
scripts in the ztools project; there's something out of date and
producing bad results. I'll fix this later today.
Cheers
Pieter
In reading all of this, I'm of a mixed mind.
Clearly there needs to be some means by which a person who's consistently a
pain in the ass for all of the wrong reasons (history of poor quality
commits, consistently more trouble of than their worth, etc.), and telling
such an individual to go away
in zmq_term docs (for both 4.1 and 4.0 for instance), the itemized list of
conditions to be satisfied shows up as -
- After interrupting all blocking calls, *zmq_term()* shall *block* until
the following conditions are satisfied: itemizedlist listitem All
sockets open within
Yet another C++ binding.
This version follows the design and conventions of Boost's Asio (see
http://www.boost.org/doc/libs/1_57_0/doc/html/boost_asio.html) library and
integrates ZeroMQ sockets into Asio's reactor machinery. It is licensed
under the same terms as Boost Asio (BOOST1.0 license).
wrote:
Hi Thomas,
Nice stuff! Here's the relevant page: http://zeromq.org/docs:organization
-Pieter
On Mon, Nov 17, 2014 at 6:06 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Yet another C++ binding.
This version follows the design and conventions of Boost's Asio (see
http
history...
On Tue, Nov 18, 2014 at 1:09 AM, Thomas Rodgers rodg...@twrodgers.com
javascript:; wrote:
Nice stuff!
Thanks!
Here's the relevant page: http://zeromq.org/docs:organization
Ask on zeromq-dev and you'll be welcomed into the organization owners'
team.
Looking back
Sweet, thanks!
I've forked the repo over to https://github.com/zeromq/aziomq and
deprecated the original repo.
On Wed, Nov 19, 2014 at 3:16 AM, Pieter Hintjens p...@imatix.com wrote:
OK, you're now invited to the ZeroMQ owners team. Welcome :-)
On Tue, Nov 18, 2014 at 1:19 PM, Thomas Rodgers
You don't need a timer per request. A typical way to do this sort of
scheduling is to keep a queue ordered by event time, by inserting each new
event into the queue by comparing event times. You set your single timer's
expiration for the event closest to now (eg the head of the queue). When
that
The biggest problem with 280, mostly idle, threads would be the amount of
stack space the OS is required to reserve (1MB for Windows/2MB for Linux).
On a 64bit host this is unlikely to be much of an issue.
On Mon, Dec 15, 2014 at 6:11 AM, Pieter Hintjens p...@imatix.com wrote:
280 threads
You need to create a WikiDot account before you can edit the page.
On Wednesday, December 24, 2014, cibercitizen1 cibercitiz...@gmail.com
wrote:
Hi all,
this is the github project:
https://github.com/cibercitizen1/zmqHelper
but don't know how to add it to the C++ bindings page.
Could
is still in raw status, what do you think of removing the
multipart from it? maybe the 3.1 will only support the new socket types.
Anyway I really excited about this change.
On Mon, Feb 2, 2015 at 4:17 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
What we really want IMO is per-peer
, but it might be platform specific.
Why wasn't it originally in end of the union which can solve the alignment
issue?
Anyway in the future we might not need it, because we can query the socket
with the routing id to get metadata.
On Mon, Feb 2, 2015 at 10:02 PM, Thomas Rodgers rodg
- deprecate REQ and REP
It would seem, given their limited utility, that marking these DEPRECATED
in the next version of libzmq would be an easy step to take.
It seems to me that in order to remove multi-part messages and introduce
new socket types (e.g. SERVER/CLIENT) that would
necessitate
What we really want IMO is per-peer metadata, and an API to get/set
this. Using messages is a hack.
Currently working on that :)
Having two layers that both
carry per-message data is... wrong IMO.
Protocols supporting 'out of band' data aren't exactly uncommon.
However the key thing is,
attempts at making `zmq_send_newfangled` a threadsafe
call.
There may be reasons this would be super gross and horrible, but it's an
idea, anyway.
-MinRK
On Fri, Feb 6, 2015 at 9:02 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Adding a mutex, even one that is never contended, to the socket
* Sessions require protocol commands that are invisible to normal
use. That means either protocol support (e.g. command frames) or some
layering on top of ZeroMQ blobs.
What would the argument be for not just using command frames for this?
On Tue, Feb 3, 2015 at 4:04 PM, Pieter Hintjens
Having thought about this for a couple of more days, I want to at least
take a stab at arguing against threadsafe sockets -
libzmq's thread safety guarantees, to me anyway, are very clear,
unsurprising and non-controversial - I cannot share a socket with another
thread without a full fence.
The
. For
the adventurous of spirit, chase down the call path of pthread_mutex
sometime in GLIBC. It is substantially more involved than a single pair of
'lock; cmpxchg' instructions, but it tries really hard to make that the
rough cost of the happy path.
On Fri, Feb 6, 2015 at 9:41 AM, Thomas Rodgers rodg
Do you see the same behavior if you replace C with fopen() ?
On Tue, Jan 20, 2015 at 7:40 AM, Olaf Mandel o.man...@menlosystems.com
wrote:
Am 20.01.2015 14:35, schrieb Olaf Mandel:
-Snipp-
#include sys/ioctl.h
#include zmq.hpp
-Snipp-
Shoot: That was missing a few include statements
I'm running your sample against current libzmq trunk, Ubuntu 14.04 and I am
unable to reproduce any leak.
On Tue, Jan 20, 2015 at 2:08 AM, Pieter Hintjens p...@imatix.com wrote:
OK, thanks for the simple test case.
I'm not familiar enough with the internals of libzmq to debug this. I
see
it manages though (at least based on my reading of
the source).
On Tue, Jan 20, 2015 at 8:56 AM, Olaf Mandel o.man...@menlosystems.com
wrote:
Hello Thomas,
thank you for the quick answer.
Am 20.01.2015 15:11, schrieb Thomas Rodgers:
Do you see the same behavior if you replace C with fopen
At least in the C++ version, the problem is relatively fragile
I always see the problem in my pure-C test
There are those that maintain that C is a simpler and more robust language
than C++ :-)~
On Tue, Jan 20, 2015 at 11:32 AM, Olaf Mandel o.man...@menlosystems.com
wrote:
Hello,
Am
I've recently been looking at msg_t and metadata_t and the general lifetime
management issues around them.
zmq::msg_t is, in some sense, not a proper C++ class, in that while it
happily possesses all of the compiler generated default operations (default
ctor, copy ctor, default dtor, default
See https://github.com/zeromq/libzmq/pull/1309
Property name is Peer-Address since this mirrors the stream_engine member
name used as the source data for the property.
On Thu, Jan 15, 2015 at 6:43 AM, Peter Kleiweg pklei...@xs4all.nl wrote:
Proposal:
zmq_msg_gets(message, Remote-Endpoint)
Is it safe to close issue #1302
https://github.com/zeromq/libzmq/issues/1302 now?
On Wed, Jan 21, 2015 at 8:13 PM, Tomas Krajca to...@repositpower.com
wrote:
Hi Thomas,
I can't reproduce the error against the latest libzmq trunk either. It
must have been fixed fairly recently because we
handling in CZMQ to handle memory
exhaustion. I don't particularly like that, as it makes things complex
and it's unclear that there's any practical strategy for apps that hit
such errors.
On Tue, Jan 27, 2015 at 8:25 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
I know sustrik has
I'm also fine just marking deprecated and reverting my size check change.
No don't do this! Preventing memory corruption can only be a good thing.
I agree, but basically makes it completely unusable in certain use cases
(as you so eloquently put it, this option is 'weird').
Anyway, unless
Excellent, I submitted issue 1296
https://github.com/zeromq/libzmq/issues/1296 to capture it. I will put
together the pull req over the weekend.
On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens p...@imatix.com wrote:
Sounds good.
On Fri, Jan 9, 2015 at 6:00 PM, Thomas Rodgers rodg
I would like to propose removing this option before it becomes part of an
officially released API, but I would like to reassurance that this is an
appropriate course of action before doing so.
My reasoning for removing it is as follows -
* It is the only option to zmq_getsockopt() that treats
:-)
On Fri, Jan 9, 2015 at 6:38 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Excellent, I submitted issue 1296 to capture it. I will put together the
pull req over the weekend.
On Fri, Jan 9, 2015 at 11:26 AM, Pieter Hintjens p...@imatix.com wrote:
Sounds good.
On Fri, Jan 9, 2015
Just a guess, are any watchpoints set in the debugging session?
On Friday, January 9, 2015, sven.koebn...@t-online.de wrote:
I get that error only during debuging inside Eclipse C++ (gdb).
It seems irrelevant, if there are breakpoints set or not (but if there are
any breakpoints, that stop
wrote:
Peter Kleiweg pklei...@xs4all.nl schreef op 8 januari 2015 03:08:50 CET:
Thomas Rodgers rodg...@twrodgers.com schreef op 8 januari 2015
02:56:18 CET:
FD ~= file descriptor.
fd_t, the type this option actually returns, is conditionally
defined
to be
int or SOCKET
This is an oddball API choice (and there is a bug in the implementation),
in that option_value* is being used as both and input and an output
parameter.
The size you pass in must be be *at least* sizeof(fd_t) bytes, because it
will overwrite the supplied identity string with the resulting file
is typedef'd to
SOCKET. On Posix systems, it's fine.
On Thu, Jan 8, 2015 at 8:28 AM, Peter Kleiweg pklei...@xs4all.nl wrote:
Thomas Rodgers schreef op de 8e dag van de louwmaand van het jaar 2015:
This is an oddball API choice (and there is a bug in the implementation),
in that option_value
struct,
they would not be happy with the result.
On Thu, Jan 8, 2015 at 9:16 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
yes.
using blob_t = std::basic_stringunsigned char;
char buf[8] = { 'f', 'o', 'o', 0, 0, 0, 0, 0 };
blob_t a(foo);
blob_t b(buf, 8);
assert(a == b); // fails
I
be in
order?
On Wed, Jan 7, 2015 at 3:37 PM, Peter Kleiweg pklei...@xs4all.nl wrote:
Thomas Rodgers schreef op de 7e dag van de louwmaand van het jaar 2015:
ZMQ_IDENTITY_FD is get only?
Yes, given a previously set socket identity (see ZMQ_IDENTITY in
http://api.zeromq.org/4-1:zmq
issue would be in order*?
On Wed, Jan 7, 2015 at 8:08 PM, Peter Kleiweg pklei...@xs4all.nl wrote:
Thomas Rodgers rodg...@twrodgers.com schreef op 8 januari 2015 02:56:18
CET:
FD ~= file descriptor.
fd_t, the type this option actually returns, is conditionally defined
to be
int
GSSAPI is documented -
http://api.zeromq.org/4-1:zmq-gssapi
all of the ZMQ_Xxx items are options are additive and documented -
http://api.zeromq.org/4-1:zmq-setsockopt
With the exception of ZMQ_SRCFD and ZMQ_SHARED which are message
properties, documented -
ZMQ_IDENTITY_FD is get only?
Yes, given a previously set socket identity (see ZMQ_IDENTITY in
http://api.zeromq.org/4-1:zmq-setsockopt), it will return the FD of the
socket associated with that identity.
On Wed, Jan 7, 2015 at 11:48 AM, Peter Kleiweg pklei...@xs4all.nl wrote:
Thomas Rodgers
I don't see any documentation for ZMQ_XPUB_NODROP
Issue submitted -
https://github.com/zeromq/libzmq/issues/1287
On Wed, Jan 7, 2015 at 11:48 AM, Peter Kleiweg pklei...@xs4all.nl wrote:
Thomas Rodgers schreef op de 7e dag van de louwmaand van het jaar 2015:
GSSAPI is documented
documented yet.
On Wed, Jan 7, 2015 at 4:04 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
GSSAPI is documented -
http://api.zeromq.org/4-1:zmq-gssapi
all of the ZMQ_Xxx items are options are additive and documented -
http://api.zeromq.org/4-1:zmq-setsockopt
With the exception
I am the author of azmq it is an active project (most recent commit within
the last week).
It is heavily tied to the way that Boost Asio does things. If you already
have/plan on having a dependency on the Boost libraries and are comfortable
with Asio then perhaps it will be a fit for you.
On
a PUB socket).
I looked to azmq CMakelists and I seems mandatory to have/use boost no?
Thanks for answering.
- Thomas Rodgers rodg...@twrodgers.com a écrit :
I am the author of azmq it is an active project (most recent commit
within
the last week).
It is heavily tied to the way
It looks like the recently added code for supporting thread safe sockets
does not support returning the signalling FD for a socket that is marked
thread safe. How would these socket types be used in a polling reactor
then?
___
zeromq-dev mailing list
Specifically, something like epoll or kqueues?
On Sat, Feb 21, 2015 at 9:27 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
It looks like the recently added code for supporting thread safe sockets
does not support returning the signalling FD for a socket that is marked
thread safe. How would
/master/src/mailbox_safe.hpp) have a
method called add signaler which is actually a file descriptor.
On Sat, Feb 21, 2015 at 5:27 PM, Thomas Rodgers rodg...@twrodgers.com
javascript:_e(%7B%7D,'cvml','rodg...@twrodgers.com'); wrote:
It looks like the recently added code for supporting thread
s/comdition/condition/
On Sat, Feb 21, 2015 at 10:45 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Which all brings us to my next question -
Can we just move on to -std=c++11 for future libzmq versions? The big 3
compilers (well mostly, Microsoft still presents a few issues) support
C++11
Which all brings us to my next question -
Can we just move on to -std=c++11 for future libzmq versions? The big 3
compilers (well mostly, Microsoft still presents a few issues) support
C++11 at this point.
Many of the issues below would just 'go away' with the use of std::mutex,
to ignore
spurious wakeups.
On Sat, Feb 21, 2015 at 10:51 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
s/comdition/condition/
On Sat, Feb 21, 2015 at 10:45 AM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Which all brings us to my next question -
Can we just move on to -std=c++11
Why would these be not compile-able with newer versions of VC (I believe
VS2008 Goes EOL in July of this year)?
Note, changing the libzmq to build with -std=c++11 would not change the C89
compatibility of it's public API.
On Saturday, February 21, 2015, André Caron andre.l.ca...@gmail.com wrote:
(but it is on the criticl path for large messages)
If you were using this approach to encode fields in some general
serialization format, maybe it would make a measurable difference, but it
seems unlikely to do so relative to framing ZeroMQ messages. In the worst
case the put|get_uint64
At the point a message is placed on the queue it is either at HWM or has at
least space for one message, this can be evaluated atomically, claiming the
'slot' under the HWM for the message to be placed on the queue. Any other
threads attempting to send would synchronize with this operation and the
.
So, ability to calculate disk usage is a likely source of confusion and
gnashing of teeth.
Right.
17.04.2015, 17:06, Thomas Rodgers rodg...@twrodgers.com
javascript:_e(%7B%7D,'cvml','rodg...@twrodgers.com');:
I suppose then it is a question of general utility. Even with ZMQ_PAIR
The pointer you passed is the args[], which is stack local. By the time the
spawned thread starts, that stack frame has been unwound and the two
contained char* are pointing to who knows what.
You must guarantee the lifetime of anything passed by pointer is sufficient
that the receiving thread
+1
libzmq has always been a C library. The canonical samples should also be
C. If the goal is clarity of intent, examples based on other language
bindings should be able to do at least as well as CZMQ as the benchmark.
On Tuesday, April 7, 2015, Brian Knox bk...@digitalocean.com wrote:
I
can you get a stacktrace?
On Thu, Apr 2, 2015 at 9:27 AM, Dario Meloni mello...@gmail.com wrote:
On Tue, 27 May 2014 10:55:57 +0100, Jon Gjengset wrote:
I have this problem constantly in a software I am developing in my
company with ZMQ 4.0.4.
The issue arise in the same situation, one
the double static_cast in an
accessor function and it compiles without C++11and seems to work.
Thanks for the suggestion,
Jens
*Von:* zeromq-dev-boun...@lists.zeromq.org [mailto:
zeromq-dev-boun...@lists.zeromq.org] *Im Auftrag von *Thomas Rodgers
*Gesendet:* Dienstag, 2. Juni 2015 19
FWIW, I made a local change to msg_t::content_t to use a type erased
zmq::atomic_counter_t and it compiles (without relaxing warnings) and
passes all tests.
On Tue, Jun 2, 2015 at 12:14 PM, Thomas Rodgers rodg...@twrodgers.com
wrote:
Current vector implementations (AFAIK) don't do small object
-dev-boun...@lists.zeromq.org] im Auftrag von Thomas Rodgers [
rodg...@twrodgers.com]
*Gesendet:* Dienstag, 2. Juni 2015 15:37
*An:* ZeroMQ development list
*Betreff:* Re: [zeromq-dev] (almost) zero-copy message receive
Personally, I think that 4 years of C++11, this should not be an
issues
Personally, I think that 4 years of C++11, this should not be an issues,
but there may be platforms with old compilers which you want to support.
4 years of C++11 *should* be enough, but wide-spread use of fully
conforming compilers is still an issue, for instance -
, you may not use
or copy or deliver this message to anyone else. In such case, you should
destroy this message and are asked to notify the sender by reply e-mail.
*From:* zeromq-dev-boun...@lists.zeromq.org [mailto:
zeromq-dev-boun...@lists.zeromq.org] *On Behalf Of *Thomas Rodgers
*Sent
1 - 100 of 133 matches
Mail list logo
