How to use _select_receive()?

QNX Newsgroups (Archives) qdn.public.qnx4.devtools
1

In the supporting documentation for select(), there is a tantalising glimpse
“under the covers” of the select() call, where it is mentioned that select()
calls a function named _select_receive(), which in turn sets up a Receive()
call specifically on its own proxy. The tantalising bit is where it is
hinted that one may write one’s own _select_receive() function and perform
QNX IPC operations behind select()'s back, so to speak, by calling Receive()
on all pids.

I figured this would be pretty useful for, say, having one’s daemon (like,
say, ntpd), respond to a sin ver query with the version of the daemon. Other
applications would no doubt spring to mind…

Unfortunately, I’m not enough of a QNX maven to work out the necessary
structure of the default _select_receive() call just from the hints given in
the select() docs. Anyone out there who would be willing to share this
secret?

Thanks,
Lyle

2

Lyle Beaulac <Lyle_C_Beaulac@attcanada.ca> wrote:
LB > In the supporting documentation for select(), there is a tantalising glimpse
LB > “under the covers” of the select() call, where it is mentioned that select()
LB > calls a function named _select_receive(), which in turn sets up a Receive()
LB > call specifically on its own proxy. The tantalising bit is where it is
LB > hinted that one may write one’s own _select_receive() function and perform
LB > QNX IPC operations behind select()'s back, so to speak, by calling Receive()
LB > on all pids.

LB > I figured this would be pretty useful for, say, having one’s daemon (like,
LB > say, ntpd), respond to a sin ver query with the version of the daemon. Other
LB > applications would no doubt spring to mind…

LB > Unfortunately, I’m not enough of a QNX maven to work out the necessary
LB > structure of the default _select_receive() call just from the hints given in
LB > the select() docs. Anyone out there who would be willing to share this
LB > secret?

This is copied from an old post right here in this newsgroup.

_select_receive( pid_t proxyPid )
{
pid_t pid;
while (1)
{
// receive whatever is available
pid = Receive( 0, buffer, len );

// if it is our proxy or error return
if( (pid == proxyPid )
|| (pid == -1) )
return pid;

// it must be a QNX message - handle it here
// you might wayt to call a message handler to
// keep _select_receive() simple
// messageHandler( pid, buffer, len );
}

// keep compiler happy
return(0);
}

3

Bill Caroselli <qtps@earthlink.net> wrote:
BC > Lyle Beaulac <Lyle_C_Beaulac@attcanada.ca> wrote:
BC > LB > In the supporting documentation for select(), there is a tantalising glimpse
BC > LB > “under the covers” of the select() call, where it is mentioned that select()
BC > LB > calls a function named _select_receive(), which in turn sets up a Receive()
BC > LB > call specifically on its own proxy. The tantalising bit is where it is
BC > LB > hinted that one may write one’s own _select_receive() function and perform
BC > LB > QNX IPC operations behind select()'s back, so to speak, by calling Receive()
BC > LB > on all pids.

BC > LB > I figured this would be pretty useful for, say, having one’s daemon (like,
BC > LB > say, ntpd), respond to a sin ver query with the version of the daemon. Other
BC > LB > applications would no doubt spring to mind…

BC > LB > Unfortunately, I’m not enough of a QNX maven to work out the necessary
BC > LB > structure of the default _select_receive() call just from the hints given in
BC > LB > the select() docs. Anyone out there who would be willing to share this
BC > LB > secret?

BC > This is copied from an old post right here in this newsgroup.

BC > _select_receive( pid_t proxyPid )
BC > {
BC > pid_t pid;
BC > while (1)
BC > {
BC > // receive whatever is available
BC > pid = Receive( 0, buffer, len );

BC > // if it is our proxy or error return
BC > if( (pid == proxyPid )
BC > || (pid == -1) )
BC > return pid;

BC > // it must be a QNX message - handle it here
BC > // you might wayt to call a message handler to
BC > // keep _select_receive() simple
BC > // messageHandler( pid, buffer, len );
BC > }

BC > // keep compiler happy
BC > return(0);
BC > }

Many thanks to ped for screwing up the indent level.

Will the damn character EVER get fixed in ped/photon?

I have now noticed that this same bug gets carried
through to the Momentics IDE editor!

4

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bjn74d$7u7$1@inn.qnx.com…

This is copied from an old post right here in this newsgroup.

_select_receive( pid_t proxyPid )
{
pid_t pid;
while (1)
{
// receive whatever is available
pid = Receive( 0, buffer, len );

// if it is our proxy or error return
if( (pid == proxyPid )
|| (pid == -1) )
return pid;

// it must be a QNX message - handle it here
// you might wayt to call a message handler to
// keep _select_receive() simple
// messageHandler( pid, buffer, len );
}

// keep compiler happy
return(0);
}

That simple? Man, now I feel really dumb. :slight_smile:

I was figuring on lifting the sys_msg() function from the Dev.ser sample
code for handling QNX system messages. Funny how lifting code, which we used
to get whacked for in school, is now considered a virtue by serving the holy
grail of code re-use.

Thank you, Bill

Lyle

5

Lyle Beaulac <Lyle_C_Beaulac@attcanada.ca> wrote:


That simple? Man, now I feel really dumb. > :slight_smile:

I was figuring on lifting the sys_msg() function from the Dev.ser sample
code for handling QNX system messages. Funny how lifting code, which we used
to get whacked for in school, is now considered a virtue by serving the holy
grail of code re-use.

You might want to lift at least a bit of the sys_msg() handling, since
you did say you wanted to get & reply to version messages.

To get version messages, you have to set PPF_SERVER (I think) in
qnx_pflags. This will get you more than just version messages –
for all the others, you have to ENOSYS them (send back a
_sysmsg_hdr_reply with status = ENOSYS I think); for version, you have
to reply with a _sysmsg_version_reply message.

(Though, you may know the above already…)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

6

David Gibbs <dagibbs@qnx.com> wrote:
DG > Lyle Beaulac <Lyle_C_Beaulac@attcanada.ca> wrote:


That simple? Man, now I feel really dumb. > :slight_smile:

I was figuring on lifting the sys_msg() function from the Dev.ser sample
code for handling QNX system messages. Funny how lifting code, which we used
to get whacked for in school, is now considered a virtue by serving the holy
grail of code re-use.

DG > You might want to lift at least a bit of the sys_msg() handling, since
DG > you did say you wanted to get & reply to version messages.

DG > To get version messages, you have to set PPF_SERVER (I think) in
DG > qnx_pflags. This will get you more than just version messages –
DG > for all the others, you have to ENOSYS them (send back a
DG > _sysmsg_hdr_reply with status = ENOSYS I think); for version, you have
DG > to reply with a _sysmsg_version_reply message.

DG > (Though, you may know the above already…)

Do make sure that you reply to all system messages though.
Otherwise you will get a hung system until the loader thread times out,
about 30 seconds, I think.

7

“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:bjqaov$ic5$1@inn.qnx.com…

David Gibbs <> dagibbs@qnx.com> > wrote:
DG > Lyle Beaulac <> Lyle_C_Beaulac@attcanada.ca> > wrote:


That simple? Man, now I feel really dumb. > :slight_smile:

I was figuring on lifting the sys_msg() function from the Dev.ser
sample
code for handling QNX system messages. Funny how lifting code, which we
used
to get whacked for in school, is now considered a virtue by serving the
holy
grail of code re-use.

DG > You might want to lift at least a bit of the sys_msg() handling,
since
DG > you did say you wanted to get & reply to version messages.

DG > To get version messages, you have to set PPF_SERVER (I think) in
DG > qnx_pflags. This will get you more than just version messages –
DG > for all the others, you have to ENOSYS them (send back a
DG > _sysmsg_hdr_reply with status = ENOSYS I think); for version, you
have
DG > to reply with a _sysmsg_version_reply message.

DG > (Though, you may know the above already…)

Do make sure that you reply to all system messages though.
Otherwise you will get a hung system until the loader thread times out,
about 30 seconds, I think.

I am trying to use the select_receive function in a photon application. Our
main loop, consists of continually making calls to select. The select
routine is
then supposed to call our select_receive function. Our select_receive
function
handles all messages by using a Receive(0,0,0). If we get matching pid, we
return else we handle the message accordingly. This includes replying to
other processes, proxies and Photon events. We then loop back and wait on
the Receive call again.

The problem seems that once we return from the select_receive function, we
are
no longer receiving any events. Our calls to select seem like the just
return without
calling our select_receive function. We can no longer process any new
events.

Are we using this correctly? Does anyone have any suggestions?

Thanks
David.