rectech wrote in message <3A59E10A.E4BB87C1@iname.com>…
Other than the version issue I haven’t had any problems with mqueues. I’ll
trying them under QRTP next month so I don’t have any experience in that
The only other things I can think of:
- there is a small period where the mq_send is blocked waiting for Mqueue
- the mqueues show up in /dev/mqueue and ls -l will show you how many are
- if the mqueue messages are printable then cat /dev/mqueue/<mqueue name
- on a network you only need one Mqueue running,
You will find that most of the QNX “regulars” have written their own
systems using the same general concept but with some added features (
some ala qnx2):
- Statistics gathering (How can you judge performance without it??)
- Broadcast to all readers vs Next reader
- Special handling for distributed networks
- Better handling of memory
- Better performance (shared memory based queuing)
From original discussions, Mqueue is “late” because it really isn’t part of
QNX but was provided for porting of POSIX applications that use it. The
original author(s) stated long ago (QUICS thread) that Mqueue (on QNX4)
was designed for legacy code and wasn’t targeted at new development.
Donald Backstrom wrote:
Unfortunately, the path that fails goes through a series of about 4
between various processes in a ring before the final process replies to
first one. It was the reply that fails (because I was stuffing up the
type somewhere in the loop) and was sending too many bytes. When I
the crash doesn’t occurr, and also if I put enought things in the
will often get the EMSGSIZE return so I suspect it is related to what
going on inside Mqueue at the time.
If I come up with something simple that can reproduce it, I’ll post it.
moment it requires NT boxes to talk to as well as QNX so I just don’t
is worth the effort until I get something simpler.
Thanks for the reply.
p.s. Mqueues are fun - we have been using them for only about 6 months
solve a lot of problems in distributed systems using Send/Receive/Reply
especially when the network is dodgy or nodes come and go. They force a
bit of a
different mindset though. It would appear though that they are a bit late
scene in QNX terms. Any other gotchas that you have noticed? The bad
a shocker and removing it solved a lot of problems. I imagine sinice it
that they exist in the RTP - do you have any experience with them there?
I have seen mq-send return EMSGSIZE (msg_len is greater than the
the mqueue) when I tried to send a message larger than the mqueue was
for but I have not seen Mqueue SIGSEGV. If you have test code post it
will try it on my system. I use mqueues heavily.
I use the Dec 1999 CD which is the 4.24A version of Mqueue you are
do not know if QNX has released anything else (ignoring the 4.24B
Donald Backstrom wrote:
I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was,
of rejecting the call, Mqueue SIGSEGVs, variously at either
or 5:0000328D. Not very friendly.
Has anybody else had this problem? Obviously the workaround is not to
it, but sometimes it takes a while to get the bugs out…