Hello, 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.
My kernel version is 3.12.28+ and I use a recent (a few commits behind HEAD) version of libzmq. On Tue, Jan 20, 2015 at 4:28 PM, Thomas Rodgers <[email protected]> wrote: > No, not really. libc++ doesn't do anything particularly interesting with > fd's but I just wanted to formally rule it out. > Unfortunately I don't have a system (or any experience dealing) with SPI > devices. I don't think libzmq does anything particularly 'funky' with any of > the file descriptors it manages though (at least based on my reading of the > source). > > On Tue, Jan 20, 2015 at 8:56 AM, Olaf Mandel <[email protected]> > wrote: >> >> 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 <fcntl.h> >> #include <linux/spi/spidev.h> >> #include <stdio.h> >> #include <string.h> >> #include <sys/ioctl.h> >> #include <zmq.h> >> >> >> /*#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; >> int fd; >> 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 >> >> >> _______________________________________________ >> 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 > -- Kapp Arnaud - Xaqq _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
