rectech wrote in message <3A59E10A.E4BB87C1@iname.com>…
Other than the version issue I haven’t had any problems with mqueues. I’ll
be
trying them under QRTP next month so I don’t have any experience in that
area yet.
The only other things I can think of:
- there is a small period where the mq_send is blocked waiting for Mqueue
to finish
some processing,
- the mqueues show up in /dev/mqueue and ls -l will show you how many are
still in
the mqueue,
- if the mqueue messages are printable then cat /dev/mqueue/<mqueue name
can be
useful,
- on a network you only need one Mqueue running,
You will find that most of the QNX “regulars” have written their own
queueing
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.
Jay
KenR
Donald Backstrom wrote:
Unfortunately, the path that fails goes through a series of about 4
mq_sends
between various processes in a ring before the final process replies to
the
first one. It was the reply that fails (because I was stuffing up the
message
type somewhere in the loop) and was sending too many bytes. When I
simplify it,
the crash doesn’t occurr, and also if I put enought things in the
debugger, I
will often get the EMSGSIZE return so I suspect it is related to what
else is
going on inside Mqueue at the time.
If I come up with something simple that can reproduce it, I’ll post it.
At the
moment it requires NT boxes to talk to as well as QNX so I just don’t
think it
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
and they
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
on the
scene in QNX terms. Any other gotchas that you have noticed? The bad
version was
a shocker and removing it solved a lot of problems. I imagine sinice it
is POSIX
that they exist in the RTP - do you have any experience with them there?
rectech wrote:
I have seen mq-send return EMSGSIZE (msg_len is greater than the
msgsize of
the mqueue) when I tried to send a message larger than the mqueue was
setup
for but I have not seen Mqueue SIGSEGV. If you have test code post it
and I
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
using. I
do not know if QNX has released anything else (ignoring the 4.24B
mistake).
KenR
Donald Backstrom wrote:
I am using Mqueue ver 4.24A, date Aug 30, 1999 which I believe to be
the
latest recognised version (see other postings for discussions on the
versions of Mqueue kicking around). I have just spent some time
chasing
a problem which turned out to be sending a message longer than the
message size for which the queue was created. The problem was,
instead
of rejecting the call, Mqueue SIGSEGVs, variously at either
5:000000A7,
or 5:0000328D. Not very friendly.
Has anybody else had this problem? Obviously the workaround is not to
do
it, but sometimes it takes a while to get the bugs out…