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" wrote:
Patch to handle SIGPIPE in send().
SIGPIPE behavior is not consistent even across *ix p
Sure, all my posts are submitted under MIT license.
On 7/6/10, Pieter Hintjens wrote:
>
>
> 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, "Dhamm
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
ever
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 ne
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, t
On Jul 6, 2010, at 1:24 PM, Martin Lucina 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 close()
> system
>
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 o
Martin,
On Tue, Jul 6, 2010 at 10:24 AM, Martin Lucina 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 close() syste
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 unpred
On Tue, Jul 6, 2010 at 9:52 AM, Martin Lucina 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 SUB s
okay, i gather you sleep before you start. fine.
i can do a handshake around the exit thing IF i can find out if
the context is finished its work. is there a way to do that?
On Jul 6, 2010, at 3:23 PM, Brian Granger wrote:
On Tue, Jul 6, 2010 at 9:52 AM, Martin Lucina wrote:
elliso...@gmail.
On 30 June 2010 20:30, Jens Mehnert 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 = ZMQ.context (1);
>
Hi.
On Tue, Jul 6, 2010 at 11:57 AM, hamster 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 feel free to contribute
On 7/6/10, Martin Lucina 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 application setti
On 7 July 2010 11:29, Dhammika Pathirana 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.
At a guess.
-
Hi Martin
On Tue, Jul 6, 2010 at 1:51 PM, Martin Lucina 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 so no f
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 hal
18 matches
Mail list logo
