sust...@250bpm.com said:
A straightforward behaviour for zmq_term would be to block until all the
sockets are deallocated -- each depending on it's SO_LINGER policy.
(This could obviously result in deadlock on zmq_term, but that's beside
the point once again I think.)
Thoughts?
For the
Hi,
I would say the zmq_close behaviour should mimic Berkeley socket close
behaviour, including SO_LINGER option and all the shutdown modes it
provides.
(One thing that strikes me is that there's no timout for trying to send
the data in the default case, which just begs to be exploited in a
i like this. and the default behaviour (depending on SO_LINGER)
would more naturally follow the expected behaviour.
On Jul 9, 2010, at 6:29 AM, Martin Sustrik wrote:
A straightforward behaviour for zmq_term would be to block until
all the
sockets are deallocated -- each depending on it's
On Wed, Jul 7, 2010 at 6:39 PM, Martin Lucina m...@kotelna.sk wrote:
Read up on the manuals for close() and setsockopt().
Following the principle of least surprise and consistency with standard
sockets, zmq_close() should not be a blocking call by default since
close() isn't either.
The
On 8/7/2010, Pieter Hintjens p...@imatix.com wrote:
On Wed, Jul 7, 2010 at 6:39 PM, Martin Lucina m...@kotelna.sk wrote:
Read up on the manuals for close() and setsockopt().
Following the principle of least surprise and consistency with standard
sockets, zmq_close() should not be a blocking
On Thu, Jul 8, 2010 at 11:19 AM, Martin Lucina m...@kotelna.sk wrote:
Almost any UNIX system call can return EINTR if it's interrupted at just
the right time, that doesn't make it a blocking call.
If it does almost nothing, then blocking and non-blocking are the
same... close() is synchronous
On Jul 8, 2010, at 6:55 AM, Matt Weinstein wrote:
IMHO the least surprising close semantics depend on the class of socket.
For example, REQ/REP or PAIR should not bother to flush, because they
are a communicating pair (temporal/ry or not), and if the
correspondent has gone away, that's
opening and closing lots of sockets is arguably bad. agreed.
not being able to close off a communication channel with
deterministic semantics is bad.
i don't understand the difficulty of being able to ask the publisher,
that is someone who has done zmq_send's, if all those sends have been
On 7/7/2010, Dhammika Pathirana dhamm...@gmail.com wrote:
But how is this different from network or remote host queuing/dropping
messages?
Sending queued messages doesn't really guarantee delivery of messages.
Of course this change doesn't *guarantee* anything has been delivered.
But that's not
On 7/7/2010, Peter Alexander vel.ac...@gmail.com wrote:
Is it time to layout a road-map document and start a zeromq3
development branch on GitHub? This should be where changes that break
backwards compatibility will go and can take shape for the next
generation of 0mq.
I realize the following
On Wed, Jul 7, 2010 at 9:23 AM, Martin Lucina m...@kotelna.sk wrote:
The confusion with the API changes in the 2.0.7 release and the resulting
stable release discussion came from the fact that Martin Sustrik and
myself had defined the 2.0.x series as Beta until such point that it
was declared
On Wed, Jul 7, 2010 at 9:35 AM, Pieter Hintjens p...@imatix.com wrote:
Does anyone see problems with this approach?
Sorry, for some reason Mato's original email slipped past me...
Mato, +1 on making zmq_term a blocking call. I'd probably make
zmq_close a blocking call as well, and offer a
On Tue, Jul 6, 2010 at 7:51 PM, Martin Lucina m...@kotelna.sk wrote:
And I'm looking for a way to dynamically change the number of
concurrent user threads available for a context, so maybe it's time
for zmq_setcontextopt()? ;-)
Probably. get/setcontextopt() are the equivalent of sysctl() or
On 7/7/10, Martin Lucina m...@kotelna.sk wrote:
On 7/7/2010, Dhammika Pathirana dhamm...@gmail.com wrote:
But how is this different from network or remote host queuing/dropping
messages?
Sending queued messages doesn't really guarantee delivery of messages.
Of course this change
On 7/7/2010, Pieter Hintjens p...@imatix.com wrote:
On Wed, Jul 7, 2010 at 9:35 AM, Pieter Hintjens p...@imatix.com wrote:
Does anyone see problems with this approach?
Sorry, for some reason Mato's original email slipped past me...
Mato, +1 on making zmq_term a blocking call.
I'd
On 7/7/2010, Dhammika Pathirana dhamm...@gmail.com wrote:
Not really, TCP close() just indicates done reading and writing. But
the OS can still send a RST (ie. receiving more data for the closed
socket), and terminate the connection.
Sure, which is fine. After a close() we don't want to receive
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
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
22 matches
Mail list logo
