Is there a hardened replacement for poll? If so, this can be modified as a compile time option.
-Pieter On Sat, Nov 10, 2012 at 8:38 PM, Michael Haberler <[email protected]> wrote: > having tried and failed, I can answer this myself: > > - the requirement for a Xenomai RT tasks is that no non-Xenomai-hardened > system calls are invoked directly or indirectly from an RT task > - however, even in non-blocking mode, zmq_recvmsg() will indirectly invoke > poll() through signaler.wait(timeout_) which is incompatible with the above > requirement. > > summary: you cannot use libzmq from Xenomai RT tasks. > > --- > > There are ways around this, but they make the point of a single, generic > interface abstraction a bit moot. > > Still, the underlying ipipe mechanism with lockfree queues would be the > perfect vehicle to use in this case, but I'm unusure how to reuse that code > directly. > > - Michael > > live from the 'ZMQ Esoteric Usescases Laboratory' > > Am 09.11.2012 um 12:26 schrieb Michael Haberler: > >> I am considering a setup of several threads cooperating through inproc queues >> >> one of those threads must be hard-realtime, with the option of using >> RT_PREEMPT or Xenomai userland threads ; a polling interface to queues >> from/to the RT thread is good enough, blocking wait is not needed >> >> >> I'd appreciated feedback if anybody has ever tried this / is interested in >> this with the Xenomai Posix skin (the RT_PREEMPT options seems relatively >> safe to do) >> >> - Michael >> >> >> >> _______________________________________________ >> 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
