I’m starting to port code from QNX4 to QNX6. So far, I’m still writing
very simply stuff to prove that my techniques are correct. And I don’t
understand what I’m seeing.
I have a server process that waits for a message. When it receives that
message it displays if and replies to it. How much simpler can you get?
I then wrote a simple client to test it. They both worked, until I
also ran psin to monitor what was going on. The scenario is as follows.
I start my server.
I start psin
I start my client. It displays some connection information.
It then sleeps for 20 seconds via sleep(20);
I go to the psin console and do a Ctrl-R to refresh the screen.
{Goofey stuff happens}
After 20 seconds, the client MsgSend()s to the server.
The server replies.
The client ends.
Both client and server are being run from a pterm. They are text mode
non-photon apps.
The Goofey stuff is that strange graphical character appear on the
screen. They appear WHEN I do the refresh in psin. Once they appear
the pterms will no longer display normal text, BUT they DO appear
to display digits appropriately when their supposed to. But letters
(a-x, A-Z) come out as graphical characters.
Slaying the pterm and reloading it does go back to normal.
I can run my tests 1000 times without doing a refresh in psin and the
pterm won’t do anything strange or unexpected.
What is psin doing to my program and what should I be doing to deal
with it properly?
It feels like my server is getting a messaeg like a ‘sin ve’ message in
QNX4 and just doesn’t know what to do with it. BUT even if that were
the case, why does it display any graphical crap on te screen?
I have confirmed that me server is receiving 3 messages from psin.
They are all coming from psin/thread 1 coid/11. And the lengths
are 60, 16, and 4 bytes respectivly.
I have confirmed that me server is receiving 3 messages from psin.
They are all coming from psin/thread 1 coid/11. And the lengths
are 60, 16, and 4 bytes respectivly.
Does anyone know WHY this is happening?
My server is receiving 3 messages from psin when psin does a refresh,
Ctrl-R. It doesn’t seam to send any messages when it is first loaded.
Also, what SHOULD my server do to reply to these messages?
Brian B <> BBarcley@everrest.net> > wrote:
I have confirmed that me server is receiving 3 messages from psin.
They are all coming from psin/thread 1 coid/11. And the lengths
are 60, 16, and 4 bytes respectivly.
Does anyone know WHY this is happening?
My server is receiving 3 messages from psin when psin does a refresh,
Ctrl-R. It doesn’t seam to send any messages when it is first loaded.
Also, what SHOULD my server do to reply to these messages?
Brian B <> BBarcley@everrest.net> > wrote:
Brian B <> BBarcley@everrest.net> > wrote:
I have confirmed that me server is receiving 3 messages from psin.
They are all coming from psin/thread 1 coid/11. And the lengths
are 60, 16, and 4 bytes respectivly.
Does anyone know WHY this is happening?
My server is receiving 3 messages from psin when psin does a refresh,
Ctrl-R. It doesn’t seam to send any messages when it is first loaded.
Also, what SHOULD my server do to reply to these messages?
This is very consisent. The only variable seams to be that sometimes
the SenderCoid is 11 and sometimes it is 12. The pid is always that
of psin.
HELP!
You are receiving messages 0x0115, 0x010E, and 0x0116, which are, respectively,
fdinfo, dup, and close. (see <sys/iomsg.h>)
You should let the resource manager framework handle all of them.
If you aren’t writing a resource manager, look at the _NTO_SIDE_CHANNEL
flag for your ChannelCreate().
(I don’t have my docs handy here; the “concept of side channel” is what you need to look into…)
Cheers,
-RK
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
You are receiving messages 0x0115, 0x010E, and 0x0116, which are, respectively,
fdinfo, dup, and close. (see <sys/iomsg.h>)
You should let the resource manager framework handle all of them.
If you aren’t writing a resource manager, look at the _NTO_SIDE_CHANNEL
flag for your ChannelCreate().
(I don’t have my docs handy here; the “concept of side channel” is what you need to look into…)
Thanks, I think.
No, I am NOT writing a resource manager, yet.
I’m looking at the man pages for ChannelCreate() and see no reference
to _NTO_SIDE_CHANNEL. Where should I be reading about this?
You are receiving messages 0x0115, 0x010E, and 0x0116, which are, respectively,
fdinfo, dup, and close. (see <sys/iomsg.h>)
You should let the resource manager framework handle all of them.
If you aren’t writing a resource manager, look at the _NTO_SIDE_CHANNEL
flag for your ChannelCreate().
(I don’t have my docs handy here; the “concept of side channel” is what you need to look into…)
Thanks, I think.
No, I am NOT writing a resource manager, yet.
I’m looking at the man pages for ChannelCreate() and see no reference
to _NTO_SIDE_CHANNEL. Where should I be reading about this?
D’oh! on the “connect”, not the create, sorry.
You no doubt do a ConnectAttach() to your server, right? That’s where…
Cheers,
-RK
\
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
I’m looking at the man pages for ChannelCreate() and see no reference
to _NTO_SIDE_CHANNEL. Where should I be reading about this?
D’oh! on the “connect”, not the create, sorry.
You no doubt do a ConnectAttach() to your server, right? That’s where…
OK. This worked. Thanks.
But I would NEVER have guessed to look there. Why does something
on the client side affect messages that psin sends to the server?
The documentation is REALLY vague about why you should do this.
Generally, until I understand WHY something is there I don’t use it.
OK, my bad. The docs did IMPLY that it was required. But the only
explanarion had to do with inheriting file descriptors. Since my
process will never fork() or exec() I didn’t think that it applied
to me.