Michael Santy wrote:
> Sounds great. Let me know how I can help.
If you want to help, I've just committed a patch to allow 0MQ queues to
rollback any unflushed messages (message parts) written to the queue.
It'll be necessary for implementing multi-part message atomicity later
on. The code con
> I would love to port these to Python if you don't mind. Could I get
> the c++/Java versions and would you mind if I used them for the Python
> version?
Please go ahead, happy to contribute. I just sent them to the list, will
resend them directly to you and Martin because I believe the lists has
Nice, hopefully it will get a bit easier soon.
--
Steve-o
On 9 March 2010 03:07, Pieter Hintjens wrote:
> Hi All,
>
> If you're using 0MQ on Windows you may be happy to find a pre-built
> build with OpenPGM here: http://www.zeromq.org/area:download-v20#toc8
>
> Note that this is the stable bet
> Yes. You are right. If there are multiple senders and multiple
receivers
> you have to have a forwarder process in the middle otherwise you would
> have to manually setup all the connections between senders and
receivers.
Ok. Any thoughts about this forwarder being a single point of failure?
>
> The first thing to think about IMO is why do you need to handle
multiple
> 0MQ sockets. Each 0MQ sockets can handle unlimited amount of
underlying
> BSD sockets so in most cases there shouldn't be a need for that kind
of
> thing (unless you want to handle different socket types at the same
time
>
Hi Gonzalo,
The first thing to think about IMO is why do you need to handle multiple
0MQ sockets. Each 0MQ sockets can handle unlimited amount of underlying
BSD sockets so in most cases there shouldn't be a need for that kind of
thing (unless you want to handle different socket types at the sam
Hi all,
I've just committed a patch that adds extensibility mechanism to 0MQ
wire format ('flags' byte).
It means that old 0MQ applications won't be able to speak to new 0MQ
applications unless you recompile them.
Martin
___
zeromq-dev mailing list
z
sust...@250bpm.com said:
> I've just committed a patch that adds extensibility mechanism to 0MQ
> wire format ('flags' byte).
>
> It means that old 0MQ applications won't be able to speak to new 0MQ
> applications unless you recompile them.
To elaborate on Martin's english compression somewhat,
gonzalo diethelm wrote:
>> Yes. You are right. If there are multiple senders and multiple
> receivers
>> you have to have a forwarder process in the middle otherwise you would
>> have to manually setup all the connections between senders and
> receivers.
>
> Ok. Any thoughts about this forwarder b
This is yet another request for your insights...
I will have a process that may be receiving incoming data on multiple
sockets (probably a couple of Upstream sockets, at least one Sub
socket). I see two designs to handle this, each with different
implications on fairness; by "fairness" I am thinki
gonzalo diethelm wrote:
> My "canonical" example is a data server: a process that reads lots of
> data from a DB and waits for messages. These messages can be of three
> kinds:
>
> 1. Queries: these would be answered very quickly from the in-memory
> data; the response will be sent somewhere else
Martin, as usual, thank you for your insightful comments. It is a
pleasure to be able to easily convey context, and receive back guidance
which is very appropriate for that context.
> Yes, right. As the queries and updates are the "same" thing (from the
> business logic point of view) it makes sen
gonzalo diethelm wrote:
>> No. The other way round. Poll will be signaled every time there's a
>> message to read in the socket.
>
> Let me be obtuse and offer an example: I will be calling poll on two
> sockets, A and B. Say I call poll and block because there are no pending
> messages; then, A
All,
I have just committed to GIT a complete rewrite of the 0MQ reference manual
included in the distribution. As many people have noted, the original
documentation was somewhat lacking.
The new rewrite aims to be a comprehensive reference for 0MQ concepts,
library functions and devices. Above al
m...@kotelna.sk said:
> The on-line documentation at http://www.zeromq.org/area:docs-v20 has been
> updated with the new manual;
A direct link to the reference index may also be useful:
http://api.zeromq.org/zmq.html
-mato
___
zeromq-dev mailing list
Further, note that the documentation for 0MQ devices is still stubbed out.
This will be updated once these stabilise.
Also, the C++ API documentation has not been updated yet, it's on my TODO
list.
-mato
___
zeromq-dev mailing list
zeromq-dev@lists.zero
Being self-taught in all things computer science Mato, I take every
opportunity to emphasize how important well thought out documentation
(especially examples) is to an OSS community.
So thank you very much for your work.
~Peter
On Tue, Mar 9, 2010 at 1:25 PM, Martin Lucina wrote:
> Further, n
Brian,
elliso...@gmail.com said:
> This example is helpful.
>
> > http://github.com/mato/zeromq-examples/blob/master/zmq-camera.c
Glad the example is useful...
> Based on the information here:
>
> http://docs.python.org/library/signal.html
>
> I think it might be possible to handle this in py
Martin, thanks for the pointer to the zmq-camera example. It handles
SIGINT/SIGQUIT etc by exiting the process. If I want to interrupt all the
blocked zmq_recv calls when receiving a SIGINT, how would you suggest me
approaching this problem? zmq_recv seems to be blocked forever.
I tool a bri
Martin,
If pthread_sigmask() is used to block any signals from interrupting the I/O
thread, how do one unblock a blocked zmq_recv? What's the alternative if we
need to do so?
Chris
On Mar 9, 2010, at 12:43 PM, Martin Lucina wrote:
> Brian,
>
> elliso...@gmail.com said:
>> This example is he
ch...@chriswongstudio.com said:
> Martin, thanks for the pointer to the zmq-camera example. It handles
> SIGINT/SIGQUIT etc by exiting the process. If I want to interrupt all the
> blocked zmq_recv calls when receiving a SIGINT, how would you suggest me
> approaching this problem? zmq_recv se
> Martin, I almost forgot, weren't we going to either change the default
> behaviour of zmq_term() or add a flag to say "Please go away NOW!"?
>
That'd be a welcomed "feature" :-)
> -mato
> ___
> zeromq-dev mailing list
> zeromq-dev@lists.zeromq.org
>
Cgris,
ch...@chriswongstudio.com said:
> If pthread_sigmask() is used to block any signals from interrupting the I/O
> thread, how do one unblock a blocked zmq_recv? What's the alternative if we
> need to do so?
When would you want to unblock a blocked zmq_recv()? The only time I can
think of
Mato,
That's the only case I can think of now also.
Chris
On Mar 9, 2010, at 12:52 PM, Martin Lucina wrote:
> Cgris,
>
> ch...@chriswongstudio.com said:
>> If pthread_sigmask() is used to block any signals from interrupting the I/O
>> thread, how do one unblock a blocked zmq_recv? What's the
All,
>> If pthread_sigmask() is used to block any signals from interrupting the I/O
>> thread, how do one unblock a blocked zmq_recv? What's the alternative if we
>> need to do so?
The blocked zmq_recv seems to be the crux of the problem.
> When would you want to unblock a blocked zmq_recv()?
Martin Lucina wrote:
> ch...@chriswongstudio.com said:
>> Martin, thanks for the pointer to the zmq-camera example. It handles
>> SIGINT/SIGQUIT etc by exiting the process. If I want to interrupt all the
>> blocked zmq_recv calls when receiving a SIGINT, how would you suggest me
>> approaching
> > The on-line documentation at http://www.zeromq.org/area:docs-v20 has
> been
> > updated with the new manual;
Thanks, this is great and will be very helpful.
I have a minor gripe / suggestion: these pages are difficult to print on
paper. This is not the case for the reference index found at
ht
>> When would you want to unblock a blocked zmq_recv()? The only time I can
>> think of doing that legitimately is when the entire application/component
>> is going away, in which case we want to change the behaviour of zmq_term()
>> as discussed in my other email.
>
> I agree that most of the tim
How deep down the pipeline is this feature at? :-) If I beg nicely, will it
float to the top of the priority list?
Chris
>
> Yes. Sane termination of blocking calls in case of zmq_term is in the
> pipeline.
>
> The idea is that once you call zmq_term on the context, all blocking
> calls wit
Gonzalo,
gdieth...@dcv.cl said:
> This is not the case for the reference index found at
> http://api.zeromq.org/zmq.html; I can Print Preview that, change the
> zoom factor and the paragraphs readjust to fit the page.
The reference manual is generated from AsciiDoc source and as such is
complete
gonzalo diethelm wrote:
> I have a minor gripe / suggestion: these pages are difficult to print on
> paper. This is not the case for the reference index found at
> http://api.zeromq.org/zmq.html; I can Print Preview that, change the
> zoom factor and the paragraphs readjust to fit the page. If I t
I looked a bit more at how Python handles these things.
>From the Python docs:
Although Python signal handlers are called asynchronously as far as
the Python user is concerned, they can only occur between the “atomic”
instructions of the Python interpreter. This means that signals
arriving during
A correction...
> Thus, I think the only way of resolving this if 0MQ is making out
> signals in the IO threads. Thoughts?
What I meant was...
Thus, I can't think of any way of resolving this if 0MQ is masking out
signal in the IO threads.
After looking a bit more, I think it might be possible
If you replace Python's sig handler, aren't you removing all the logics in
Python's sig handler, whatever Python may have to do.
Chris
On Mar 9, 2010, at 1:37 PM, Brian Granger wrote:
> A correction...
>
>> Thus, I think the only way of resolving this if 0MQ is making out
>> signals in the IO
Chris,
> If you replace Python's sig handler, aren't you removing all the logics in
> Python's sig handler, whatever Python may have to do.
Yep, and this is what makes this subtle and non-ideal. But, you can
set/unset this signal handler each time
zmq_recv is called, and make it play well with
When zmq_send is called, it returns immediately which is good. AFAIK, the
message will be eventually sent out by the IO thread.
If zmq_close is called on the socket before the message got sent out from the
IO thread, the pending message seem to get removed without getting sent out.
Is there an
Hello,
I intend to create a fairly complex networking topology using zmq_rep and
zmq_req sockets. I have a couple questions:
1. When using IPC as the transport method, after binding a zmq_rep socket
to an IPC pathname, can I have multiple zmq_req sockets connect to that same
pathname and expect
I wrote two small apps: one binds a PUB socket to an endpoint and sends
N messages to it; the other connects a SUB socket to that same endpoint
and receives N messages. The sender optionally can wait a certain amount
of ms between each send, and it always waits for 60 seconds at the end.
I am attac
On Tue, Mar 09, 2010 at 07:26:34PM -0300, gonzalo diethelm wrote:
> I wrote two small apps: one binds a PUB socket to an endpoint and sends
> N messages to it; the other connects a SUB socket to that same endpoint
> and receives N messages. The sender optionally can wait a certain amount
> of ms be
Chris,
> How deep down the pipeline is this feature at? :-) If I beg nicely, will it
> float to the top of the priority list?
The issue has to do with the technically most complex part of the
codebase (async shutdown), thus it needs some time window to be
implemented and thoroughly tested. No
Hi Brian,
>> Thus, I think the only way of resolving this if 0MQ is making out
>> signals in the IO threads. Thoughts?
>
> What I meant was...
>
> Thus, I can't think of any way of resolving this if 0MQ is masking out
> signal in the IO threads.
>
> After looking a bit more, I think it might b
Chris,
> When zmq_send is called, it returns immediately which is good. AFAIK,
> the message will be eventually sent out by the IO thread.
>
> If zmq_close is called on the socket before the message got sent out
> from the IO thread, the pending message seem to get removed without
> getting sen
Emit Sorrels wrote:
>> This works erratically. Sometimes receiver receives less than 20
>> messages; sometimes it receives NONE.
>>
>> Is it the case that PUB/SUB sockets are unreliable? This is sort of a
>> surprise to me... If they are not, what could explain this behavior?
>> Thanks in advance.
43 matches
Mail list logo
