Re: [zeromq-dev] czmq: Error Traceability with assert(...) and release code
Am 07.03.2014 15:13, schrieb Christoph Zach: > We are currently planing on using czmq (directly and implicitly via zyre) to > implement > some distributed services. By browsing the demo applications and the source > We found out that there are various places where 'assert( ... )' is used. > This caused > one of the demo applications (compiled as release) to crash. > Hello Christoph, I assume you mean that an assertion is violated and either: * you did not specify NDEBUG so the assertion is still checked and calls abort() or * you did specify NDEBUG so the assertion is a no-op and the crash ahppens further down in the code In either case, an assertion should only be violated for real codeing-bugs (czmqs or your applications), not for any runtime errors. If it is the latter, then using an assertion is actually a bug in czmqs. > To further use zyre/czmq We are planing on replacing all the assert(...) > statements > with actual error handling routines. Otherwise, if one of our applications > crashes on a customer's system We have to put in a lot of effort to find out > what actually happend (which is really complex/expensive when the system is > not > remotely accessible). -Snipp- See my claim above. If an assertion is miss-used for run-time checks, that should definitely be fixed. Either way, try defining NDEBUG for your release binaries: this will not call abort() but will do the null-pointer dereference, the beyond-array-bounds access or whatever the assertion was about. This may (or may not) be easier to debug than an assertion, depending on your code. Best regards, Olaf signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Relicensing CZMQ & other projects
Am 20.03.2014 10:57, schrieb Pieter Hintjens: -Snipp- > It's not practical to relicense libzmq to MPLv2, however it is for > other projects. We're starting with CZMQ, and will broaden this to > other projects over time. > > Does anyone have objections to this shift? If not, I'll document it on > the wiki page as a recommendation for new projects. The C4.1 process > already has MPLv2 as an allowed license. Hello, can you clarify: do you plan to add the MPLv2 to the existing LGPLv3 license or do you plan to replace the LGPLv3 with the MPLv2? The latter might be troublesome as anyone creating a (L)GPL binary would then dual-license CZMQ anyway. Is this really simpler for legal teams than the static linking exception? As I am not a lawyer, my opinion is based on info "stolen" from https://www.gnu.org/licenses/license-list.html#MPL-2.0 Best regards, Olaf signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] ZMQ vs SPI: FD shenanigans
Hello,
I was trying to use ZMQ in a C++ program that also uses the STL to open
regular files and that uses the open(2) and ioctl(2) syscalls of the
Linux kernel for SPI communication (on an ARM platform). For certain
combinations of opening and closing a regular file and binding to a TCP
or Inproc socket, a subsequent ioctl call fails with either "No such
device" or "Resource temporarily unavailable".
My first guess is that somehow ZMQ is messing up the file descriptors it
uses, but I am certainly not ready to rule out bugs in the STL, Kernel
or (least probably): my own code :-)
Could anyone give me a suggestion on how continue debugging this?
This is my demo code of the problem. The code uses the C++ binding for
ZMQ (cppzmq) for brevity, but it should work the same for the native C
interface.
#include
#include
//#define ADDR "tcp://127.0.0.1:8000"
#define ADDR "inproc://addr"
/*
* The program works fine if D is present and it shows the problem if
* D is commented out for the following permutations of the blocks:
* - A B C D
* - A C B D
* - C A B D
*
* The program always shows the problem (independent of the presence
* of D) for the following permutations of the blocks:
* - A C D B
* - C A D B
* - C D A B
*
* With the constraint that A must be before B and C before D, there
* are no further valid permutations.
*
* For the TCP address, the error message is: No such device
* For the inproc address, it is: Resource temporarily unavailable
*/
int main()
{
zmq::context_t ctx;/* A */
zmq::socket_t skt(ctx, ZMQ_PUB); /* B */
skt.bind(ADDR);
std::fstream fs("log", std::ios::out); /* C */
fs.close();/* D */
/* The following always last */
int fd = open("/dev/spidev32766.0", O_RDWR);
struct spi_ioc_transfer pcks;
memset(&pcks, 0, sizeof(struct spi_ioc_transfer));
ioctl(fd, SPI_IOC_MESSAGE(1), &pcks);
std::cout << "errno: " << strerror(errno) << std::endl;
return 0;
}
Thank you for any suggestion,
Olaf Mandel
--
Olaf Mandel
phone: +49-89-189166-250
fax: +49-89-189166-111
Menlo Systems GmbH
Am Klopferspitz 19a, D-82152 Martinsried
Amtsgericht München HRB 138145
Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth
USt-IdNr. DE217772017, St.-Nr. 14316170324
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans
Am 20.01.2015 14:35, schrieb Olaf Mandel: -Snipp- > > > #include > #include -Snipp- Shoot: That was missing a few include statements at the top the program and the compile instructions. Correct start of the demo program: /* * Compile with: * g++ -Wall -Werror -Wextra -o test test.cpp -lzmq */ #include #include #include #include #include #include Sorry about that, Olaf Mandel -- Olaf Mandel phone: +49-89-189166-250 fax: +49-89-189166-111 Menlo Systems GmbH Am Klopferspitz 19a, D-82152 Martinsried Amtsgericht München HRB 138145 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth USt-IdNr. DE217772017, St.-Nr. 14316170324 signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans
Hello Thomas,
thank you for the quick answer.
Am 20.01.2015 15:11, schrieb Thomas Rodgers:
> Do you see the same behavior if you replace C with fopen() ?
-Snipp-
Not quite: if the error occurs, the behaviour is the same as before. But
now the error _always_ happens: closing the file descriptor in the C
version of the test makes no difference. New test below:
/*
* Compile with:
* g++ -Wall -Werror -Wextra -pedantic -x c -o test test.c -lzmq
*/
#include
#include
#include
#include
#include
#include
/*#define ADDR "tcp://127.0.0.1:8000"*/
#define ADDR "inproc://addr"
/*
* The program always shows the problem (independent of the presence
* of D) for the following permutations of the blocks:
* - A B C D
* - A C B D
* - A C D B
* - C A B D
* - C A D B
* - C D A B
*
* With the constraint that A must be before B and C before D, there
* are no further valid permutations.
*
* For the TCP address, the error message is: No such device
* For the inproc address, it is: Resource temporarily unavailable
*/
int main()
{
void* ctx;
void* skt;
FILE* f;
intfd;
struct spi_ioc_transfer pcks;
ctx = zmq_ctx_new();/* A */
skt = zmq_socket(ctx, ZMQ_PUB); /* B */
zmq_bind(skt, ADDR);
f = fopen("log", "w"); /* C */
(void)sizeof(f);
fclose(f); /* D */
/* The following always last */
fd = open("/dev/spidev32766.0", O_RDWR);
memset(&pcks, 0, sizeof(struct spi_ioc_transfer));
ioctl(fd, SPI_IOC_MESSAGE(1), &pcks);
printf("errno: %s\n", strerror(errno));
return 0;
}
The one advantage of this is: I now at least can see the FILE structure
and the contained _fileno member.
Any further thoughts?
Olaf Mandel
--
Olaf Mandel
phone: +49-89-189166-250
fax: +49-89-189166-111
Menlo Systems GmbH
Am Klopferspitz 19a, D-82152 Martinsried
Amtsgericht München HRB 138145
Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth
USt-IdNr. DE217772017, St.-Nr. 14316170324
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans
Hello, Am 20.01.2015 18:07, schrieb Arnaud Kapp: > I don't really see anything in the small example that could cause a bug. > I am myself using libzmq (with zmqpp as a wrapper) on a Raspberry Pi + > a Piface digital card (which is a SPI device), and I have no trouble. > At least in the C++ version, the problem is relatively fragile: it only occurs if mixing ZMQ socket operations binds/connects with opening and closing files. There are cases where I also don't see the problem. Weirdly, I always see the problem in my pure-C test... > My kernel version is 3.12.28+ and I use a recent (a few commits behind > HEAD) version of libzmq. -Snipp- Good point, my machine and version numbers are: CPU: Freescale i.MX537 (Cortex-A8, NEON) GCC: 4.8.1, cross-compiling Linux: 3.10.28 + many platform patches ZMQ: zeromq/libzmq.git @ be23e699c Any other info of interest? Best regards, Olaf Mandel -- Olaf Mandel phone: +49-89-189166-250 fax: +49-89-189166-111 Menlo Systems GmbH Am Klopferspitz 19a, D-82152 Martinsried Amtsgericht München HRB 138145 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth USt-IdNr. DE217772017, St.-Nr. 14316170324 signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans
Hello, Am 20.01.2015 22:02, schrieb Arnaud Kapp: -Snipp- >> On Tue, Jan 20, 2015 at 11:32 AM, Olaf Mandel >> wrote: -Snipp- >>> Good point, my machine and version numbers are: >>> >>> CPU: Freescale i.MX537 (Cortex-A8, NEON) >>> GCC: 4.8.1, cross-compiling >>> Linux: 3.10.28 + many platform patches >>> ZMQ: zeromq/libzmq.git @ be23e699c >>> -Snipp- > I see two things to try: > * Try with a more stable version of libzmq - > https://github.com/zeromq/zeromq4-1 > * Upgrading to a more recent kernel and to gcc 4.9 if those are available. > this took a while, but I have now recompiled the complete system (including kernel) with GCC 4.9.2. I will not be able to go for a newer kernel: that has quite a few patches and porting those is a somewhat daunting task for me. The behaviour seems the same with the following combinations of ZeroMQ and GCC: ZeroMQ w/ GCC: 4.0.5 w/ 4.8.1 HEAD w/ 4.8.1 HEAD w/ 4.9.2 4.1.0 w/ 4.9.2 I want to check a bit why C and C++ behave differently tomorrow. Any further suggestions anyone could make? Best regards, Olaf Mandel -- Olaf Mandel phone: +49-89-189166-250 fax: +49-89-189166-111 Menlo Systems GmbH Am Klopferspitz 19a, D-82152 Martinsried Amtsgericht München HRB 138145 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth USt-IdNr. DE217772017, St.-Nr. 14316170324 signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] ZMQ vs SPI: FD shenanigans
Hello, Am 21.01.2015 22:31, schrieb KIU Shueng Chuan: > Are you sure that the ioctl call failed? You are printing out errno without > having checked the return code of the ioctl call. -Snipp- that actually was the problem!!! My own code had more debug checks to verify that none of the previous calls failed. But that debug code never checked the contents of errno before the end! zmq_bind() may return successfully (zmq_bind() == 0), but it still leaves errno non-equal to zero. And in my "real" program I didn't use the return code of the ioctl call but the errno value. Thank you for helping me find this! Now the question: is it proper behaviour of zmq_bind() to change errno to a non-success value and then return successfully? Or should ZMQ everywhere that it works around "temporary" errors reset errno to zero on success? Best regards, Olaf Mandel -- Olaf Mandel phone: +49-89-189166-250 fax: +49-89-189166-111 Menlo Systems GmbH Am Klopferspitz 19a, D-82152 Martinsried Amtsgericht München HRB 138145 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth USt-IdNr. DE217772017, St.-Nr. 14316170324 signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Handling high socket or connection counts
Hello,
I was wondering if there is any pattern to handle many open connections
to a single socket or many open sockets in one executable: I
consistently run into a "Too many open files" problem.
I get this error either when I run into the ZMQ_MAX_SOCKETS limit or
into the operation system resource limit (ulimit -n) on Linux. On
Windows, I can be lucky not to cause a Bluescreen!
I therefore assume this is a general design question, not a specific
problem with 0MQ.
Background: I was considering a program design consisting of many
independent parts that run in many different threads and must exchange
data. I was planning to expose the readable/manipulable properties via
0MQ REQ-REP and PUB-SUB sockets, via the inproc or tcp transport. But in
the naive approach the number of possible sockets and connections in one
executable is too low:
* one file descriptor per socket
* for tcp, one file descriptor per connection
The number needed in my case ranges from a few hundred sockets to many
thousands (configuration dependent) and I don't even know how many
connections I might end up having...
My REQ-REP test-case, stripped of all checks:
#include
#include
int main() {
void* context = zmq_ctx_new();
void* server = zmq_socket(context, ZMQ_REP);
zmq_bind(server, "tcp://127.0.0.1:");
std::vector clients;
for(unsigned int i=0; i<2048; ++i) {
clients.push_back(zmq_socket(context, ZMQ_REQ));
zmq_connect(clients.back(), "tcp://127.0.0.1:");
}
return 0;
}
The full test case is available under http://pastebin.com/hN4PYkX3 .
Any insight is much appreciated!
Thank you,
Olaf Mandel
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Handling high socket or connection counts
Am 06.02.2014 16:09, schrieb Goswin von Brederlow: > On Thu, Feb 06, 2014 at 01:38:48PM +0100, Olaf Mandel wrote: -Snipp- >> I get this error either when I run into the ZMQ_MAX_SOCKETS limit or >> into the operation system resource limit (ulimit -n) on Linux. On >> Windows, I can be lucky not to cause a Bluescreen! >> -Snipp- >> >> * one file descriptor per socket >> * for tcp, one file descriptor per connection >> -Snipp- > [...] When you use > threads then you should be using inproc. That only uses a bit of > memory (right?) and no file descriptors at all. Problem solved. > Hello, and thank you for the quick reply. It is true that I mixed up hitting the ZMQ_MAX_SOCKETS limit and hitting the OS limit: I only use up file descriptors for tcp, not for inproc. So on *nix using inproc is definitely feasible. But on Windows (which I have to support as well), this will not work: I have a segmentation fault when connecting the 1021st client socket. Is this a known equivalent of *nix "ulimit -n"? > But what if you don't use threads? Then inproc won't work. But also > you don't have a limit of 1024 sockets. Only 1024 file descriptors per > executable. By forking or starting seperate executables you can have > many more sockets, colletively. How much more? There are only 65536 > ports and 0-1023 is reserved for root. So you won't get verry far with > tcp. If you need more then you need to use multiple hosts or at least > containers with different IPs. > -Snipp- A good point: I thought I was save because I only bind to very few port numbers and mostly connect. But even a socket that connects to a different port on localhost still consumes a second port number, doesn't it? I didn't consider this. So from the point of view of my original question: one approach is to use inproc where possible, reducing the reliance on tcp sockets? Best regards, Olaf Mandel -- Olaf Mandel phone: +49-89-189166-250 fax: +49-89-189166-111 Menlo Systems GmbH Am Klopferspitz 19a, D-82152 Martinsried Amtsgericht München HRB 138145 Geschäftsführung: Dr Michael Mei, Dr Ronald Holzwarth USt-IdNr. DE217772017, St.-Nr. 14316170324 signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Handling high socket or connection counts
Am 06.02.2014 18:50, schrieb Michel Pelletier: > It's true a client can only make ~60K outgoing connections (due to > ephemeral port exhaustion) but a server with bound sockets can have up to > 64K connections _per port_. Here's a blog post from urban airship > detailing their experiments with pushing connection limits up to 500K on a > single machine: > > http://urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/ -Snipp- > I was wrong by a similar order of magnitude, it's per port per client. > > http://stackoverflow.com/questions/2332741/what-is-the-theoretical-maximum-number-of-open-tcp-connections-that-a-modern-lin > > It's basically unlimited. -Snipp- Hello, thank you for the two links: the stackoverflow post certainly answers the question of number of connections allowed. And the urbanairship post actually gives me a feeling what kind of performance to aim for :-) Best regards, Olaf Mandel signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] Poller choice in configure or poller.hpp
Hi, I noticed that there are two mechanisms to decide which poller (devpoll,epoll,kqueue,poll,select) to use: * poller.hpp makes a choice based on the operation system (e.g. ZMQ_HAVE_LINUX or ZMQ_HAVE_WINDOWS) unless overridden by one of the ZMQ_FORCE_* macros. * configure uses the LIBZMQ_CHECK_POLLER function from acinclude.m4 to detect which poller to use. This can be confusing to the casual reader of poller.hpp, as LIBZMQ_CHECK_POLLER may make a different choice than the include file would have made. In my case: ZMQ_HAVE_CYGWIN but ZMQ_FORCE_POLL, and I didn't realise that the configure script sets one of the ZMQ_FORCE_* macros. Now my first question: is this particular example (Cygwin and poll) a bug and where? ZMQ_USE_POLL works for me up to a 1021 sockets, while ZMQ_USE_SELECT works only up to 28 (!) sockets. What is the "correct" default for Cygwin? And my second question: is there a need and way to make the potential ambiguity clearer? Possible answers: * no, any developer is supposed to check the configure output very carefully * just add a comment to poller.hpp that configure sets one of the ZMQ_FORCE_* macros * make the two mechanisms give the same result, if possible * remove the poller.hpp selection mechanism Comments? Best regards, Olaf Mandel signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Poller choice in configure or poller.hpp
Hi, Am 14.02.2014 13:01, schrieb Pieter Hintjens: > On Fri, Feb 14, 2014 at 11:38 AM, Olaf Mandel > wrote: > >> Now my first question: is this particular example (Cygwin and poll) a >> bug and where? ZMQ_USE_POLL works for me up to a 1021 sockets, while >> ZMQ_USE_SELECT works only up to 28 (!) sockets. What is the "correct" >> default for Cygwin? > > When poll() is available it generally works better than select().[...] Now the question becomes: does Cygwin _always_ provide poll(): then poller.hpp should be updated. Or is this only on my system? > [...] It's > rather surprising that select() only handles 28 sockets. > Opened an issue on this: https://github.com/zeromq/libzmq/issues/893 >> And my second question: is there a need and way to make the potential >> ambiguity clearer? > > Sounds like cleaning this up would be beneficial. Two mechanisms to do > the same work feels bogus. Either poller.hpp should choose, or > configure should choose. I think the FORCE macros were originally > meant as a manual override; they've then been abused for Cygwin, and > perhaps elsewhere. Then the question becomes: is the mapping from a used operation system to the best available poller constant? Then implement it into poller.hpp and remove the configure code. If there is even a chance that the best poller on an operation system is optional (i.e. may be missing), then keep the configure code and clean out poller.hpp. Are either Martin Sustrik (who last touched the poller.hpp code in question) or Mikko Koppanen (who wrote the LIBZMQ_CHECK_POLLER configure function) on this list and have any insight? Best regards, Olaf Mandel signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] Poller choice in configure or poller.hpp
Am 15.02.2014 12:43, schrieb Pieter Hintjens: > On Fri, Feb 14, 2014 at 2:30 PM, Olaf Mandel > wrote: > >> Now the question becomes: does Cygwin _always_ provide poll(): then >> poller.hpp should be updated. Or is this only on my system? > > Assume we don't know, and the simplest solution is to assume Cygwin > always provides poll(), and if not, someone will yell. -Snipp- Hi, I decided to go the other way and completely remove the code that chooses the poller mechanism from poller.hpp. Now I rely on the configure script to make the choice: pull req #899 But before this can be considered for inclusion into master, can someone review / test it? Thank you, Olaf Mandel signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
[zeromq-dev] How should sockets be destroyed?
Hello,
I am currently trying to open and close many sockets and run into the
MAX_SOCKETS limit, even though only one socket should be open at a time.
Basically I do (return value checks removed for readability):
int const l = 0;
int i;
for(i=0; i<1; ++i) {
socket = zmq_socket(context, ZMQ_REP);
rc = zmq_setsockopt(socket, ZMQ_LINGER, &l, sizeof(l)); /* #1 */
rc = zmq_connect(socket, "inproc://demo");
rc = zmq_close(socket);
}
The socket creation fails in zmq::ctx_t::create_socket() at
if(empty_slots.empty ()) { /*fail*/ } .
Note 1: The presence or absence of zmq_setsockopt() makes no difference.
When trying to figure out what happens on zmq_close(), I run into
zmq::socket_base_t::check_destroy(), which never seems to do anything.
It simplifies down to the following:
if (destroyed) { // set by zmq::socket_base_t::process_destroy()
/*destroy fd and socket, send notification to preaper*/
zmq::own_t::process_destroy();
}
Here socket_base_t::process_destroy() is a virtual overload of
own_t::process_destroy(), and it seems to be called from a single place:
zmq::own_t::check_term_acks() . But I lack the background to understand
this if-statement which is never true:
if(terminating && processed_seqnum == sent_seqnum.get () &&
term_acks == 0) {
/* ... */
process_destroy();
}
So my question boils down to: is this expected behaviour and I am doing
something wrong (like failing to call another close-function in addition
to zmq_close()) or is this a known or new bug in ZMQ?
Thanks for any insight,
Olaf Mandel
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How should sockets be destroyed?
Am 24.02.2014 11:43, schrieb Laurent Alebarde:
> Where is your socket variable declaration ?
-Snipp-
>
> Le 24/02/2014 11:32, Olaf Mandel a écrit :
-Snipp-
>>
>> int const l = 0;
>> int i;
>> for(i=0; i<1; ++i) {
>> socket = zmq_socket(context, ZMQ_REP);
>> rc = zmq_setsockopt(socket, ZMQ_LINGER, &l, sizeof(l)); /* #1 */
>> rc = zmq_connect(socket, "inproc://demo");
>> rc = zmq_close(socket);
>> }
>>
-Snipp-
Hello Laurent,
the socket is declared outside of the loop. Here is the full code, again
without assertions and debug output:
#include
int main(void)
{
int const l = 0;
void* context;
void* socket;
int rc;
int i;
context = zmq_ctx_new();
for(i=0; i<1; ++i) {
socket = zmq_socket(context, ZMQ_REP);
rc = zmq_setsockopt(socket, ZMQ_LINGER, &l, sizeof(l));
rc = zmq_connect(socket, "inproc://demo");
rc = zmq_close(socket);
}
rc = zmq_ctx_destroy(context);
return 0;
}
> You shall use one variable per socket, so, use an array.
After the zmq_close() call, I was expecting it to be ok to reuse the
socket variable, same like you may reuse a pointer-variable after
deleting the original contents. And if there really is a need to keep a
reference to the socket after the zmq_close() call, that would actually
be my original question: how to properly close a socket to that it is
really closed?
Best regards,
Olaf Mandel
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How should sockets be destroyed?
Am 24.02.2014 12:12, schrieb Olaf Mandel:
-Snipp-
> for(i=0; i<1; ++i) { /*...*/ }
Hi,
I noticed a second, possibly related issue: when reducing number of loop
iterations (even down to a single iteration!), the call to
zmq_ctx_destroy() fails. In zmq::pipe_t::check_write() a check is made
if the socket state is "active", but it is "waiting_for_delimiter".
Best regards,
Olaf Mandel
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How should sockets be destroyed?
Am 24.02.2014 12:21, schrieb Diego Duclos: > As far as I'm aware, the closing happens on the network thread, which means > that by the time your loop reaches the socket limit, the sockets probably > haven't been closed yet ? > On Mon, Feb 24, 2014 at 11:32 AM, Olaf Mandel > wrote: -Snipp- >> When trying to figure out what happens on zmq_close(), I run into >> zmq::socket_base_t::check_destroy(), which never seems to do anything. -Snipp- >> Here socket_base_t::process_destroy() is a virtual overload of >> own_t::process_destroy(), and it seems to be called from a single place: >> zmq::own_t::check_term_acks() . [...] -Snipp- Hello Diego, I just ran a test with a 100ms sleep inserted in my loop: I still fail at exactly the same socket number. The socket does not seem to be closed at all. Best regards, Olaf Mandel signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How should sockets be destroyed?
Am 24.02.2014 15:50, schrieb Diego Duclos:
> You'd probably need to add two sleeps: 1 after creation to wait for the
> socket to be properly created. And another after the destruction to wait
> for the socket to be properly destroyed.
>
Hi Diego,
I now tried with this loop with two sleeps:
for(i=0; i<1; ++i) {
socket = zmq_socket(context, ZMQ_REP);
Sleep(100);
rc = zmq_setsockopt(socket, ZMQ_LINGER, &l, sizeof(l));
rc = zmq_connect(socket, "inproc://demo");
rc = zmq_close(socket);
Sleep(100);
}
After some minutes this fails at the same point for the same reason:
zmq_socket() returns 0 for socket number 1023 with an errno of EMFILE.
BTW: I tried removing zmq_connect() and the sleep, so using a loop of
only zmq_socket(), zmq_close() and I no longer get the error.
Please note that I don't bind anything to the inproc address in this
example: the connection never gets established. The same pattern emerges
if I first bind a socket to the address and then run the
conenct-disconnect loop: abort after the number of sockets gets exhausted.
> Most importantly though: Why do you need to do this ? It seems like quite
> the antipattern in ZMQ development ?
>
-Snipp-
Actually: no. This is straight from the guide, "Lazy Pirate Pattern": if
there is an error that requires two sends on a REQ socket, close the old
socket and use a new socket. Just in the guide, they give up after a few
tries. My code didn't give up so eventually ran into this problem
(actually, for TCP I usually crash my PC). The loop is just in the test
case.
Best regards,
Olaf Mandel
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How should sockets be destroyed?
Am 24.02.2014 18:04, schrieb Laurent Alebarde: > By default, you are allowed 1024 sockets per context. After having > created the context, you shall increase the quantity of sockets allowed: > > rc = zmq_ctx_set (ctx, ZMQ_MAX_SOCKETS, 1); > assert (rc == 0); > -Snipp- Hello Laurent, maybe I am just unclear on the documentation and intended behaviour: is ZMQ_MAX_SOCKETS intended to be the number of sockets for the context at any one time or is it the absolute number of sockets that may be created over the life-time of the context? In the latter case I don't think REQ-REP with e.g. the Lazy Pirate Pattern work for long-running programs: they would eventually run out of sockets to create. Best regards, Olaf Mandel signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How should sockets be destroyed?
Am 24.02.2014 18:09, schrieb Laurent Alebarde:
> As you are using LINGER, the sockets stays alive for the time specified.
> In your test, where you want absolutly to use one variable, you shall
> set LINGER to 0.
-Snipp-
As per one of my earlier posts, that is what I did:
> int main(void)
> {
> int const l = 0;
> ...
> rc = zmq_setsockopt(socket, ZMQ_LINGER, &l, sizeof(l));
> ...
And the problem persists with or without ZMQ_LINGER.
Best regards,
Olaf Mandel
signature.asc
Description: OpenPGP digital signature
___
zeromq-dev mailing list
zeromq-dev@lists.zeromq.org
http://lists.zeromq.org/mailman/listinfo/zeromq-dev
Re: [zeromq-dev] How should sockets be destroyed?
Am 25.02.2014 12:32, schrieb KIU Shueng Chuan: > Is this related to the following issue? > https://github.com/zeromq/libzmq/issues/792 > -Snipp- Hello Shueng Chuan, thank you for the link: I seem to have the same problem as described in #792. I tried with TCP transport and could not reproduce the error. I will leave a comment in #792 that I could reproduce the error under Windows: maybe we can find the differences between d70-t and my test case. Any idea on how to continue for debugging? Best regards, Olaf Mandel signature.asc Description: OpenPGP digital signature ___ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
