David Gibbs wrote:
David Dickey <> email@example.com> > wrote:
Someone is trying to port some code from qnx4 to RTP.
He is having a problem from time to time with MsgSend returning EINVAL (22).
This happens when using pulses. No pulses, no problems.
Since I’m the “someone” and asked Dave D ickey to post this problem for me (I
didn’t have access to inn.qnx.com for the last 4 days – and thanks to Dave for
doing that for me), here some further explanations :
I think there is some confusion here – either in what he is doing, or
in your understanding of what he is doing. The MsgSend() function is
not involved with pulses at all. Pulses can be sent with either a
MsgDeliverEvent() call or a MsgSendPulse() call and received with
MsgReceivev or MsgReceivePulsev. In no case is MsgSend()
Basically, what’s being done is the following :
Our application library starts a receiver task for each task which is in charge
of receiving messages from external tasks (or it’s owning task). This receiver
notifies the parent task thru a proxy (via Trigger() ) once a message has
arrived and ends up again in Receive(). The parent task , now waiting in
Receive() as well, invokes Send() to the receiver task to get the message, the
message comes back when the receiver task invokes Reply() to this message.
Here is were it becomes a bit complicated : All calls to Send() and Receive() are
wrapped in our application library to also fire a timer to trigger a additional
proxy to itself after a certain timeout period to be notified if the receiver
task went booboo() or other mishaps prevented Send() or Receive() from returning.
Now after invoking this mechanism a few hundred times, the Send() call to the
receiver task returns -1 and errno is set to 22 (EINVAL). The amount of messages
processed appears to vary, I havent found the exact reason. I played with the
number of threads in mig4nto-procmgr, didn’t seem to have a an effect – although
just simply restarting the procmgr seems to have an effect sometimes.
If I take the timeout / proxy code out, I wasn’t yet able to recreate the
problem. (but we loose the ability to detect send(), ,receive() timeouts).
He is trying to convert code that used proxies. the migration library
has him using pulses now. His code will work for some period of time
and then get the error code above. This is not a documented error for
Note also that MsgSend() can return undocumented error codes –
remember the MsgError() function will cause MsgSend() to return -1
and set errno to the value passed to MsgError(). Also, if -1 is
passed as the status field in a MsgReply(), it will look like
MsgSend() failed, and in that case errno may have garbage data.
Please also note that we are not ready yet to go completely to QNX/NTO, the code
needs to build under QNX4, thats why I need the migration library.
Besides the code, what other info is needed?
What version of NTO is he running? But, mainly, the source to
look at would probably help.
QNX neutrino 6.00 2000/04/28-13:55:35edt x86pc x86
I’m just trying to extract the actual problem regions out of that application
library, which is quite huge. I’m not going to be able to post it to inn.qnx.com,
but I will mail it to you seperately later, since our companies have a NDA, that
shouldn’t be a problem.
Thanks for any help you could give me with that.