Patch to handle SIGPIPE in send().
SIGPIPE behavior is not consistent even across *ix platforms. Linux
has MSG_NOSIGNAL and Mac supports SO_NOSIGPIPE. Best option is to set
SIG_IGN, but it's more of an application setting. We should document
this.
diff --git a/src/tcp_connecter.cpp
Dhammika,
Thanks for the patch. We'll apply it asap. Please confirm you submit it
under MIT license... thanks.
-Pieter
Sent from my Android mobile phone.
On Jul 6, 2010 8:01 AM, Dhammika Pathirana dhamm...@gmail.com wrote:
Patch to handle SIGPIPE in send().
SIGPIPE behavior is not consistent
Hello!
I am a newbie with 0mq so I beg my pardon if this question looks boring, yet
quick overview of docs/faqs/maillist gave me no answer.
Is there any way to setup two-way 0mq communication in usual client-server
style? I mean the server which listens on a given port and then forks for
every
dhamm...@gmail.com said:
Patch to handle SIGPIPE in send().
SIGPIPE behavior is not consistent even across *ix platforms. Linux
has MSG_NOSIGNAL and Mac supports SO_NOSIGPIPE. Best option is to set
SIG_IGN, but it's more of an application setting. We should document
this.
Why would we need
elliso...@gmail.com said:
I have run into this many times. The issue is that the SUB socket
doesn't get the messages until it actually connects:
If the PUB starts before the SUB, the PUB will start broadcasting
before the SUB starts and the SUB won't get those messages that were
sent
Hi all,
while implementing a 0MQ architecture which needs to dynamically create and
destroy sockets during operation I ran into the current behaviour of
zmq_close() being semantically different from the standard close() system
call.
Consider a scenario where we wish to send a bunch of messages,
matt_weinst...@yahoo.com said:
In my opinion the proper solution is to use the same semantics as the
close() system call, in other words, zmq_close() shall invalidate the
socket from the caller's point of view so no further operations may be
performed on it, but 0MQ shall send any
Martin,
On Tue, Jul 6, 2010 at 10:24 AM, Martin Lucina m...@kotelna.sk wrote:
Hi all,
while implementing a 0MQ architecture which needs to dynamically create and
destroy sockets during operation I ran into the current behaviour of
zmq_close() being semantically different from the standard
Oh, I forgot the mention another point about this.
I have started to put time.sleep(?) calls at the end of my zmq
applications because of this. But, this has a huge problem that is
almost impossible to fix with the current API. The amount of time I
need to sleep before calling zmq_term is
On Tue, Jul 6, 2010 at 9:52 AM, Martin Lucina m...@kotelna.sk wrote:
elliso...@gmail.com said:
I have run into this many times. The issue is that the SUB socket
doesn't get the messages until it actually connects:
If the PUB starts before the SUB, the PUB will start broadcasting
before the
On 30 June 2010 20:30, Jens Mehnert jens.mehn...@smeet.com wrote:
Hello Steve, thanks for the quick answer. What about my other problem.
Isn't it possible to bind /connect a sender/receiver
to two different sockets on the same interface like this:
private static final ZMQ.Context CONTEXT =
Hi.
On Tue, Jul 6, 2010 at 11:57 AM, hamster yidiepxgx...@spammotel.com wrote:
Hello!
I am a newbie with 0mq so I beg my pardon if this question looks boring, yet
quick overview of docs/faqs/maillist gave me no answer.
Yeah doc organization is still a work in progress. But as your
learning
On 7/6/10, Martin Lucina m...@kotelna.sk wrote:
dhamm...@gmail.com said:
Patch to handle SIGPIPE in send().
SIGPIPE behavior is not consistent even across *ix platforms. Linux
has MSG_NOSIGNAL and Mac supports SO_NOSIGPIPE. Best option is to set
SIG_IGN, but it's more of an
On 7 July 2010 11:29, Dhammika Pathirana dhamm...@gmail.com wrote:
How does 0MQ ignore signals? I don't see a signal handler or SIG_IGN flag.
Default SIGPIPE behavior is to terminate the process.ore
It ignores them by not handling them at all. The application developer
needs to manage them.
Hi Martin
On Tue, Jul 6, 2010 at 1:51 PM, Martin Lucina m...@kotelna.sk wrote:
matt_weinst...@yahoo.com said:
In my opinion the proper solution is to use the same semantics as the
close() system call, in other words, zmq_close() shall invalidate the
socket from the caller's point of view
But how is this different from network or remote host queuing/dropping
messages?
Sending queued messages doesn't really guarantee delivery of messages.
This gets even worse as TCP sends RST (ECONNRESET) on receiving data
to a closed socket. In http world they work around this by sender
doing a
16 matches
Mail list logo
