sin,psin,procnto messages

[Francois Joubert]

I have a service waiting for messages:

rcvid = MsgReceive(...

I get messages from sin, psin and procnto(pid=1). My message structure
will not allow these messages to cause any harm, but why do they send
these messages and what is the response they require?

Francois

[Colin Burgess]

They are most likely IO_DUP and IO_FDINFO messages.

You should set the _NTO_SIDE_CHANNEL flag on your channel to indicate that your channel is not an 'fd'.

Colin

Francois Joubert wrote:

I have a service waiting for messages:

rcvid = MsgReceive(...

I get messages from sin, psin and procnto(pid=1). My message structure
will not allow these messages to cause any harm, but why do they send
these messages and what is the response they require?

Francois

--
cburgess@qnx.com

[Francois Joubert]

Colin Burgess wrote:

They are most likely IO_DUP and IO_FDINFO messages.

You should set the _NTO_SIDE_CHANNEL flag on your channel to indicate
that your channel is not an 'fd'.

Colin

Francois Joubert wrote:
I have a service waiting for messages:

rcvid = MsgReceive(...

I get messages from sin, psin and procnto(pid=1). My message structure
will not allow these messages to cause any harm, but why do they send
these messages and what is the response they require?

Francois

Thank you for the info. My problem however was that I use name_attach in

this instance. I did not handle received messages properly as clearly
described in the documentation.

[Colin Burgess]

You can setup your own channel, and the use

dispatch_t *_dispatch_create(int chid, unsigned flags);

instead of the normal dispatch_create().

Francois Joubert wrote:

Colin Burgess wrote:
They are most likely IO_DUP and IO_FDINFO messages.

You should set the _NTO_SIDE_CHANNEL flag on your channel to indicate
that your channel is not an 'fd'.

Colin

Francois Joubert wrote:
I have a service waiting for messages:

rcvid = MsgReceive(...

I get messages from sin, psin and procnto(pid=1). My message
structure will not allow these messages to cause any harm, but why do
they send these messages and what is the response they require?

Francois

Thank you for the info. My problem however was that I use name_attach in
this instance. I did not handle received messages properly as clearly
described in the documentation.

--
cburgess@qnx.com

[qnxloader]

When you do name_open, coid will be start from _NTO_SIDE_CHANNE, so
you should not get IO_DUP and IO_FDINFO from utilities sin, ...; am
I right?

[Francois Joubert]

qnxloader wrote:

When you do name_open, coid will be start from _NTO_SIDE_CHANNE, so
you should not get IO_DUP and IO_FDINFO from utilities sin, ...; am
I right?

I received _IO_DEVCTL messages.

Francois

[Ken Schumm]

"Francois Joubert" <sommerfj@webmail.co.za> wrote in message
news:fcod24$1c8$1@inn.qnx.com...

qnxloader wrote:
When you do name_open, coid will be start from _NTO_SIDE_CHANNE, so
you should not get IO_DUP and IO_FDINFO from utilities sin, ...; am
I right?

I received _IO_DEVCTL messages.

The QNX doc and examples for using name_open do seem to be incomplete. Using
the 'on' utility with such code also cause these messages to be sent. I've
always had to ignore _IO_DEVCTL and _IO_DUP when using name_open().

[David Gibbs]

Francois Joubert <sommerfj@webmail.co.za> wrote:

qnxloader wrote:
When you do name_open, coid will be start from _NTO_SIDE_CHANNE, so
you should not get IO_DUP and IO_FDINFO from utilities sin, ...; am
I right?

I received _IO_DEVCTL messages.

You shouldn't, true. But qconn, sin, pidin, etc aren't neccessarily as
bright as they should be about not issuing queries on things that aren't
fds.

A general principle in ALL servers: if you get a message that you don't
understand/expect, return an error. I tend to prefer:

MsgError(rcvid, ENOSYS);

-David
--
David Gibbs
QNX Training Services
dagibbs@qnx.com