Hi Jarred,
Did the same code change the other day, and can also confirm that it works.
If I recall, all the compiler warnings were because of the 8-byte size_t
on x64. I didn't dive any deeper than just reading the warnings.
Here is the fix to get the CLR bindings to run against either
Hi Piotr,
Not for speed, I need it to automatically define unique-name io
channel
between cores on the same host.
My process setup:
- k processes on same host (not threads)
- each process can communicate with the other on the same host
- each process has a dedicated
-Original Message-
From: zeromq-dev-boun...@lists.zeromq.org [mailto:zeromq-dev-
boun...@lists.zeromq.org] On Behalf Of Joe Holloway
Sent: Wednesday, 14 April, 2010 19:51
To: 0MQ development list
Subject: Re: [zeromq-dev] jzmq UnsatisfiedLinkError on Linux
On Wed, Apr 14, 2010 at
avbid...@fortytwo.ch said:
On Sunday 11 April 2010 19.29:53 Wolfgang Barth wrote:
On Sun, Apr 11, 2010 at 05:49:18PM +0200, Adrian von Bidder wrote:
I'd go with 2.0.6+1d28dc-1. Or possibly 2.0.6+git1d28dc-1
Why not using git-dch (see my previous mail)?
If the current version in
Hello Everybody,
I work at SAP Research Lab in Belfast and I am interested in
dedicating some of my research effort to HP messaging in the context
of the ZEROMQ project.
Could you please indicate me possible research lines that could be
interesting for your development and also with an strong
All,
as part of some API and naming cleanups (more to core) that we'd like to do
before the 2.0.7 release I would like to solicit comments for/against
renaming the ZMQ_P2P socket type to ZMQ_PAIR.
Rationale: The name ZMQ_P2P evokes a) peer-to-peer networks such as
Bittorrent et al. b) many to
On Thu, Apr 15, 2010 at 5:52 PM, Brian Candler b.cand...@pobox.com wrote:
Sorry, that was more of a braindump than I was intending :-)
Any chance you can post this to that page?
-Pieter
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
All,
with the introduction of more send/recv flags (ZMQ_SNDMORE), socket options
(ZMQ_RCVMORE) and the experimental device api (ZMQ_STREAMER et al) the ZMQ_
namespace for constants is starting to look rather ad-hoc and crowded.
There are two main motivations for doing the cleanup. Firstly,
Martin Lucina wrote:
// Account for both 0MQ sockets and file descriptors.
union zmq_poll_item_t
{
void *socket;
int fd;
};
Why a union type? Will that not be potentially problematic for some
languages?
Yes. More over it is not clear how to distinguish between raw sockets
I am not a member of iMatix nor a developer on the 0MQ team, so am being a bit
rude by responding to your note - Martin S., please forgive me!
One of the most difficult areas with software the nature of 0MQ is exactly the
one you are thinking of: Latency monitoring and adjustment. Given
sust...@250bpm.com said:
Martin Lucina wrote:
// Account for both 0MQ sockets and file descriptors.
union zmq_poll_item_t
{
void *socket;
int fd;
};
Why a union type? Will that not be potentially problematic for some
languages?
Yes. More over it is not clear
Hi Indefons, John,
I am not a member of iMatix nor a developer on the 0MQ team, so am
being a bit rude by responding to your note - Martin S., please
forgive me!
Well, you've worked on the VMS port plus COBOL and Fortran bindings, no?
That makes you part of the team :)
Actually, if anyone
On Apr 15, 2010, at 11:18 AM, Martin Lucina wrote:
All,
as part of some API and naming cleanups (more to core) that we'd like to do
before the 2.0.7 release I would like to solicit comments for/against
renaming the ZMQ_P2P socket type to ZMQ_PAIR.
Rationale: The name ZMQ_P2P evokes a)
Martin,
// Account for both 0MQ sockets and file descriptors.
union zmq_poll_item_t
{
void *socket;
int fd;
};
Why a union type? Will that not be potentially problematic for some
languages?
Yes. More over it is not clear how to distinguish between raw sockets
and 0MQ
I am not too excited about this change as the current API is pretty
well established and the new convention simply makes all of use type
more. But, I spend a lot of my time in the Python universe, where
flat is better than nested. (I view the proposal as a sort for
pseudo=nesting).
Cheers,
On Thu, Apr 15, 2010 at 9:58 AM, Martin Lucina m...@kotelna.sk wrote:
sust...@250bpm.com said:
Martin Lucina wrote:
// Account for both 0MQ sockets and file descriptors.
union zmq_poll_item_t
{
void *socket;
int fd;
};
Why a union type? Will that not be potentially
Chuck Remes wrote:
Given that the ZMQ_P2P socket is for communication between a PAIR of peers,
the name ZMQ_PAIR is more accurate, and also in line with e.g. POSIX calls
such as socketpair().
Comments?
I think this new name better describes the intent. I like it.
Current P2P socket is
Hi all,
Just figured I'd drop a quick note about the research I am involved in. We
don't do research on 0mq, but it is used in our research. It's slightly off
topic for subjects to research but sometimes it helps just to know what
others are doing. First a bit on what we are looking at:
We are
Erich Heine wrote:
Hi all,
Just figured I'd drop a quick note about the research I am involved in.
We don't do research on 0mq, but it is used in our research. It's
slightly off topic for subjects to research but sometimes it helps
just to know what others are doing. First a bit on what
I have an application that needs to send out a message as soon as possible
without waiting for the optimistic batching. Latency is more important than
message throughput. Is there a switch I can use with zmq_setsockopt to disable
batching? I looked at the man page but couldn't find anything
On Thu, Apr 15, 2010 at 7:47 PM, Chuck Remes cremes.devl...@mac.com wrote:
Given that the ZMQ_P2P socket is for communication between a PAIR of peers,
the name ZMQ_PAIR is more accurate, and also in line with e.g. POSIX calls
such as socketpair().
+1 from me.
Some alternatives to stir into
ch...@chriswongstudio.com said:
I have an application that needs to send out a message as soon as possible
without waiting for the optimistic batching. Latency is more important than
message throughput. Is there a switch I can use with zmq_setsockopt to
disable batching? I looked at the
Ah shoot. I really need that. I'll try to resurrect it. What would be a good
alternative name for it?
Maybe it should come back as a socket option?
Thoughts?
Chris
On Apr 15, 2010, at 5:44 PM, Martin Lucina wrote:
ch...@chriswongstudio.com said:
I have an application that needs to send
ch...@chriswongstudio.com said:
Ah shoot. I really need that. I'll try to resurrect it. What would be a
good alternative name for it?
Maybe it should come back as a socket option?
Thoughts?
The original zmq_flush() and the accompanying ZMQ_NOFLUSH flag to send was
really more of a
* I'd also like to see some documentation of the on-the-wire protocol. I
haven't read through all the white papers yet, but I don't see it at first
glance. This is partly for idle curiosity, but also for the possibility of
implementing a pure-ruby version. I would have to understand the
I was stumbling around the code and found a out_batch_size in config.hpp. I
wonder what would happen if I lower that value. :-)
A hint is better than nothing, I suppose. I don't mind that it's getting sent
out in the background I/O as soon as possible without a hard guarantee at the
app
On 4/15/10, Martin Lucina m...@kotelna.sk wrote:
All,
with the introduction of more send/recv flags (ZMQ_SNDMORE), socket options
(ZMQ_RCVMORE) and the experimental device api (ZMQ_STREAMER et al) the ZMQ_
namespace for constants is starting to look rather ad-hoc and crowded.
There are
There is an example in the man page of zmq_strerror.
Basically, it uses the same thread-local errno variable. Not sure if it's
thread-local on Windows though.
Chris
On Apr 11, 2010, at 9:36 PM, Derek Developer wrote:
From the docs:
The ØMQ library functions handle errors using the
Chris,
0MQ does not batch when there's nothing to batch. The only situation
when batching happens is when network is not fast enough to transport
messages. In such case messages are queued and sent later on in batches
to improve throughput.
I was stumbling around the code and found a
29 matches
Mail list logo
