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 probably more important.
STREAM sockets probably should finish, PUB sockets should probably
finish. etc.
A more important is that whereas TCP is in the kernel, ØMQ is not, and
their lifetimes are different, which means you could still close(),
then exit() from another thread, and it would be an unpleasant
"surprise" if you expected close() to finish sending, and it didn't.
Right now, I'd say the simplest way might be to add a way of finding
out if a socket is "busy" doing stuff you asked it to, which allows
you to wait if you want to. You could do this e.g. by adding
getsockopt(ZMQ_IOPEND).
Then you can hang around waiting for completion:
for (;;) {
int64_t working;
int rc = zmq_getsockopt (psocket, ZMQ_IOPEND, &working, sizeof working);
assert (rc == 0);
if (! working) {
rc = zmq_close(psocket);
assert(rc == 0);
break;
}
usleep(10000);
}
Obviously this can be wrapped, error checked, etc.
On Jul 8, 2010, at 5:38 AM, Pieter Hintjens wrote:
> On Thu, Jul 8, 2010 at 11:19 AM, Martin Lucina <[email protected]>
> 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 even if it does nothing. fclose()
> flushes data and that could conceivably block exactly as I'm
> suggesting zmq_close() would block, if it flushed messages to the OS.
>
> Given that we don't have any scenarios that prove or disprove this
> solution, it's pretty irrelevant. We need to flush messages at some
> stage before exiting the process, and we need to add this without
> changing the API.
>
> Opinions from others would be welcome. Does a zmq_close() which
> flushes pending messages make sense? Or is that too surprising?
>
> I'm sure when Sustrik gets back from his week off he'll have a good
> answer to this :-)
>
> -Pieter
> _______________________________________________
> zeromq-dev mailing list
> [email protected]
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________
zeromq-dev mailing list
[email protected]
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
