Am 10.11.2012 um 12:49 schrieb Pieter Hintjens: > Is there a hardened replacement for poll? If so, this can be modified > as a compile time option. > > -Pieter
not as far as I can tell, Xenomai RT tasks live outside file descriptor land, other than when using the RT_PREEMPT patch for RT tasks Xenomai brings its own memory allocation, queues, pipes, events, semaphore interfaces - the full monty of a private API (http://www.xenomai.org/documentation/trunk/html/api/group__native.html) the application should be portable wrt the RT kernel anyway, so delving into Xenomai API's is not my preferred option since the RT task is cyclical to start with, polling is fine, so I'd rather go a layer lower and use ipipe directly which would be portable (methinks; I need to verify if that would be free of system calls and accessible for mortals) barring that, Paul Colomiet's pipe_template.h saves the day for a mere 250 lines of code. Not what I wanted, but cheap and portable. -- are there any thoughts about defining a public API for user-defined socket types? - Michael > 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 _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
