I’m interested in using the asycn message passing mechanism in QNX - I don’t need (Ir want) my calling sever to block whenever it sends. (My background is using simple OSs where you send events that get clients to wake up and read from mailboxes, so pulses and async messages seem to perfect for this, especially as my clients will be picking up different types of events from other sources.)
I only found this mechanism by accident - it’s not highly publicized in the QNX web pages but seems perfect for what I want to do.
Has anyone got any “gotchas” or any experience with this library?
If you read the Architectural manual, a really good idea when starting with QNX you will see that Pulses are well documented.
You can use mqueue
With threads its rather easy to have non-blocking messages
Most new users of QNX that I’ve run into who are looking for ways to get asynchronous messages are misunderstanding something fundamental about the way things work.
I have read it. I only came across the async messages feature by accident - I don’t know why you mentioned pulses. They’re fairly well documented.
I know. This is a under consideration, as it’s likely we’re going to ditch QNX for Linux in the near future and it may be a requirement to be posix compliant to minimize porting.
Well of course it is, that wasn’t my question.
And this misunderstanding is? I asked the question to get some helpful advice, not patronised. Maybe when you’ve stopped showing off you could elucidate.
At the moment I’m just investigating all possibilities, as QNX seems to offer plenty of choices for IPC, whether it’s the standard QNX Synchronous Messages, POSIX message queues, Pulses, Pipes, et al.
QNX offers native async messaging, so I didn’t have to “find a way to do it”.
I found the async API document (qnx.com/developers/docs/6.3. … aging.html) which looks like a recent(ish) addition to the OS, and was wondering if anyone here had any experience with it. I have no idea why using a feature that’s clearly been added due to demand is “on the wrong track”… QNX must have added this API to support the sort of event based messaging capabilities you find in most embedded OSs. It’s sometimes not ideal for a sender to block whilst waiting a reply.
Architecturally, the design so far is OS agnostic, but implementation-wise, the world’s my oyster. Portability to Linux may or may not be a deciding factor on the underlying IPC mechanism, depending on future direction which isn’t yet clear. It’s just one consideration of many.
It’s early in the project and there’s a still a chance we might be using another OS anyway. At the moment it’s QNX so I’m simply getting to grips with the thing…
Yep Flapdoodle I think for Automotive the new PPS is very useful. That you haven’t seen it yet is because it was just introduced with the new version 6.5. This new version also supports lazylinking, which increases boot speed with large C++ applications, which typically are used in Automotive space, so that may be a plus for you, too.
Btw. I recommend you to subscribe to the QNX Newsletter “The Source”. It’s short, not stuffed with marketing bla-bla, and has interesting news items on a regular basis… I think PPS was mentioned there.
I was thinking along the same lines as you with portability to Linux. I found an open source project ZeroMQ recently that may or may not work on QNX. I haven’t tried it but I believe it should work. The PREEMPT-RT project is moving rapidly to reduce latency in the kernel. The one thing missing was a nice message passing api and from what I can tell ZeroMQ may just fit most of my requirements. If you get a chance to try it out please post you results.