MOSTMAN <christian.richter@soft-gate-dot-de.no-spam.invalid> wrote:
Hi!
Thanks for your helps!!
Problem was I didn’t install SP1.
That would cause problems, yes.
Now I can read and write into the mq - Message Queue.
In the former SW-Project there are operations of treating the with
mq_open() created
Message Queue-descriptor like a file descriptor
such as FD_SET
to add the m.q.-descriptor to the File-Deskr.-Set
to check with select() if new messages arrived in the message queue.
Can I solve this problem by using mq_notify()?
If they were ONLY using select() for mqs, you can fairly easily work
around this with mq_notify(). (See below…)
If they were using select() for mq_ds, and for sockets, pipes, consoles,
or anything else filedescriptor based, the structure starts to get a bit
more complicated. If this is the case, if the code was multiplexing through
select() for mqueues and non-mqueues, this is a non-portable use of mqueues
(POSIX does not require that this be possible) though many implementations
do allow it, including our mqueue implementation. But, for this case, it
may be worth examining why you wish to switch to mq, rather than mqueue,
and whether the code complexity introduced is worth it. Were you seeing
performance problems/bottlenecks with mqueue? Were you moving big messages,
or lots of messages, and the savings in mq is worth the cost of the code
changes? It may not be worth switching. If you do switch, the two main
methods would be to go multi-threaded, one thread for select() on non mqs,
the other for mq_notify() on mqs. This does require proper mutexing of any
and all shared data structures, conflicting code paths, and all the other
complexities of a threaded implementation. The other choice would be to
convert to mq_notify() for the mqs, and io_notify() for all the other fds.
(See below on mq_notify useage.)
If you were only using select() for mqueues, then the conversion to
mqs is not too bad. If you want to maintain a POSIX environment, you
would have to use signals, and I’d use data carrying signals, but I
would generally prefer to do this using pulses. (Signals cause some…
complications… cause they interrupt things, but with queued data
carrying signals, properly masked, you should do ok.)
Basic structure:
chid = ChannelCreate();
coid = ConnectAttach( chid, … _NTO_SIDE_CHANNEL, … );
for each queue:
mqd_t = mq_open(…, O_NONBLOCK,…);
SIGEV_PULSE_INIT( &ev, coid, CODE_MQUEUE, mqd_t); // value is mqd
mq_notify(mq_d, &ev );
// drain queue
while( (ret = mq_receive()) != -1 && errno != EWOULDBLOCK )
process queue entry or error
while(1)
MsgReceive()
if (msg.pulse.code == CODE_MQUEUE )
mqd = msg.pulse.value.sival_int;
SIGEV_PULSE_INIT( &ev, coid, CODE_MQUEUE, mqd); // value is mqd
mq_notify(mqd, &ev );
// drain queue
while( (ret = mq_receive()) != -1 && errno != EWOULDBLOCK )
process queue entry or error
Keys: mq_notify() is 1) only empty to non-empty for read, and 2) removed
after each notification, so: must attach notification, then drain to empty
to activate, then on each notification must attach notification then drain
to empty else will never be notified again.
Maybe you want to just stick with select() and mqueue? 
-David
David Gibbs
QNX Training Services
dagibbs@qnx.com