sin ve: How to make my process to show up?

QNX Newsgroups (Archives) qnx.qnx4
1

How to make a process to show up in the “sin version” output?

Tony.

2

Tony wrote:

How to make a process to show up in the “sin version” output?

Set _PPF_SERVER in qnx_pflags().

You will then receive type = _SYSMSG / subtype = _SYSMSG_SUBTYPE_VERSION
messages (in your normal server Receive() loop) from “sin ver” queries.

Respond with a
struct _version_reply {
struct _sysmsg_hdr hdr;
struct _sysmsg_version_reply data;
};
all filled-in with appropriate content.

Refer to <sys/sys_msg.h> for more details …

3

On Sun, 10 Oct 2004 14:05:04 +1300, John Garvey <jgarvey@qnx.com> wrote:

How to make a process to show up in the “sin version” output?
Set _PPF_SERVER in qnx_pflags().
You will then receive type = _SYSMSG / subtype = _SYSMSG_SUBTYPE_VERSION
messages (in your normal server Receive() loop) from “sin ver” queries.

The application is not genuine QNX4, it is a ported UNIX code. Where can I find the whole example to put in?

Tony.

4

Tony <mts.spb.suxx@mail.ru> wrote:

On Sun, 10 Oct 2004 14:05:04 +1300, John Garvey <> jgarvey@qnx.com> > wrote:

How to make a process to show up in the “sin version” output?
Set _PPF_SERVER in qnx_pflags().
You will then receive type = _SYSMSG / subtype = _SYSMSG_SUBTYPE_VERSION
messages (in your normal server Receive() loop) from “sin ver” queries.

The application is not genuine QNX4, it is a ported UNIX code. Where can
I find the whole example to put in?

If it is ported UNIX code, it may not work. Does it use a Receive() as
a common blocking point? If not, you won’t be able to handle these
messages without a fair bit of recoding, that is probably beyond what
you want to do.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

5

David Gibbs <dagibbs@qnx.com> wrote:
DG > Tony <mts.spb.suxx@mail.ru> wrote:

On Sun, 10 Oct 2004 14:05:04 +1300, John Garvey <> jgarvey@qnx.com> > wrote:

How to make a process to show up in the “sin version” output?
Set _PPF_SERVER in qnx_pflags().
You will then receive type = _SYSMSG / subtype = _SYSMSG_SUBTYPE_VERSION
messages (in your normal server Receive() loop) from “sin ver” queries.

The application is not genuine QNX4, it is a ported UNIX code. Where can
I find the whole example to put in?

DG > If it is ported UNIX code, it may not work. Does it use a Receive() as
DG > a common blocking point? If not, you won’t be able to handle these
DG > messages without a fair bit of recoding, that is probably beyond what
DG > you want to do.

It boils down to, you need a loop like this:

while(true)
{
Receive()
switch( message_type )
{
_SYSMSG:
switch( subtype)
{
version_request:
reply_with_version_info
}
}
}

However, you MUST reply to this message immediately. If you program
isn’t constantly waiting to receive messages, you don’t want to use this.

P.S. I wish they implemented this feature in QNX6.
It is incredibly useful.

6

On 12 Oct 2004 12:44:08 GMT, David Gibbs <dagibbs@qnx.com> wrote:

The application is not genuine QNX4, it is a ported UNIX code. Where can
I find the whole example to put in?
If it is ported UNIX code, it may not work. Does it use a Receive() as
a common blocking point?
No, there is no such a beast…

Could I just add a module where the server loop with the Receive() would be set up? Or, when trying to run that module I will have to do it in a separate thread since just calling it from somewhere in the UNIX code would not return (i.e. block) preventing the main UNIX code from functioning properly?

Tony.

7

Tony <mts.spb.suxx@mail.ru> wrote:

On 12 Oct 2004 12:44:08 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:

The application is not genuine QNX4, it is a ported UNIX code. Where can
I find the whole example to put in?
If it is ported UNIX code, it may not work. Does it use a Receive() as
a common blocking point?
No, there is no such a beast…
Could I just add a module where the server loop with the Receive() would
be set up?

As you surmised, this would block your process – not what you want.

Or, when trying to run that module I will have to do it in a separate
thread since just calling it from somewhere in the UNIX code would not
return (i.e. block) preventing the main UNIX code from functioning
properly?

QNX4’s threading is somewhat lacking. The “thread” would actually show
up as a 2nd process entry, I think, which would answer the ‘sin ver’
message – but wouldn’t look quite like the same process, though it should
have the same process name. i.e. it wouldn’t be perfect, but it might
work. (QNX4’s “thread” setup is, really, a 2nd process entry that shares
the same code & data segment as the creating process.)

Make sure to make the qnx_pflags() call in the thread, so that process
will get the version request.

Also, keep to a minimum what the thread does – this shouldn’t be a problem
for your case, as all you want it to do is reply with a version message.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

8

On 12 Oct 2004 18:00:20 GMT, David Gibbs <dagibbs@qnx.com> wrote:

Make sure to make the qnx_pflags() call in the thread, so that process
will get the version request.

Also, keep to a minimum what the thread does – this shouldn’t be a problem
for your case, as all you want it to do is reply with a version message.
This is what qnx.org.ru people advised me with:

#include <errno.h>
#include <stdio.h>
#include <sys/kernel.h>
#include <sys/psinfo.h>
#include <sys/sys_msg.h>

#define MY_NAME “myname”
#define MY_VERSION 100
#define MY_LETTER ‘A’

int
main(int argc, char *argv[])
{
static const struct _sysmsg_version_reply ver = {
MY_NAME,
DATE,
MY_VERSION,
MY_LETTER
};

struct _sysmsg_hdr_reply rhdr;
struct _sysmsg_hdr shdr;
struct _mxfer_entry rmx[2];
pid_t pid;
int rc;

rc = qnx_pflags(_PPF_SERVER, _PPF_SERVER, 0, 0);
if (rc == -1) {
perror(“qnx_pflags failed”);
return 1;
}

while (1) {
pid = Receive(0, &shdr, sizeof(shdr));
if (pid == (pid_t)-1) {
perror(“Receive failed”);
break;
}

switch (shdr.type) {
case _SYSMSG :
switch (shdr.subtype) {
case _SYSMSG_SUBTYPE_VERSION :
printf(“recv system version msg”);
rhdr.status = 0;
_setmx(&rmx[0], &rhdr, sizeof(rhdr));
_setmx(&rmx[1], &ver, sizeof(ver));
Replymx(pid, 2, rmx);
break;

default :
printf(“recv unknown system msg”);
rhdr.status = ENOSYS;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
break;

default :
printf(“recv unknown msg”);
rhdr.status = EINVAL;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
}
return 0;
}

Now I have to find a way to run it as the second thread.

Tony.

9

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opsfrtc4gqo93ri4@mobile.wst.quantum.ru…

On 12 Oct 2004 18:00:20 GMT, David Gibbs <> dagibbs@qnx.com> > wrote:

Make sure to make the qnx_pflags() call in the thread, so that process
will get the version request.

Also, keep to a minimum what the thread does – this shouldn’t be a
problem
for your case, as all you want it to do is reply with a version message.
This is what qnx.org.ru people advised me with:

#include <errno.h
#include <stdio.h
#include <sys/kernel.h
#include <sys/psinfo.h
#include <sys/sys_msg.h

#define MY_NAME “myname”
#define MY_VERSION 100
#define MY_LETTER ‘A’

int
main(int argc, char *argv[])
{
static const struct _sysmsg_version_reply ver = {
MY_NAME,
DATE,
MY_VERSION,
MY_LETTER
};

struct _sysmsg_hdr_reply rhdr;
struct _sysmsg_hdr shdr;
struct _mxfer_entry rmx[2];
pid_t pid;
int rc;

rc = qnx_pflags(_PPF_SERVER, _PPF_SERVER, 0, 0);
if (rc == -1) {
perror(“qnx_pflags failed”);
return 1;
}

while (1) {
pid = Receive(0, &shdr, sizeof(shdr));
if (pid == (pid_t)-1) {
perror(“Receive failed”);
break;
}

switch (shdr.type) {
case _SYSMSG :
switch (shdr.subtype) {
case _SYSMSG_SUBTYPE_VERSION :
printf(“recv system version msg”);
rhdr.status = 0;
_setmx(&rmx[0], &rhdr, sizeof(rhdr));
_setmx(&rmx[1], &ver, sizeof(ver));
Replymx(pid, 2, rmx);
break;

default :
printf(“recv unknown system msg”);
rhdr.status = ENOSYS;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
break;

default :
printf(“recv unknown msg”);
rhdr.status = EINVAL;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
}
return 0;
}

Now I have to find a way to run it as the second thread.

_beginthread( main… )

You will have to change main arguments since a thread only takes one
pointer. You will also have to deal with thread termination.

Tony.

10

On Tue, 12 Oct 2004 18:22:26 -0400, Mario Charest <nowheretobefound@8thdimension.com> wrote:

Now I have to find a way to run it as the second thread.
_beginthread( main… )

You will have to change main arguments since a thread only takes one
pointer. You will also have to deal with thread termination.

I think I’ll comment out all printf’s and change main there to “void main(void)”.
By the way, should I give this server a name of it’s own?

_beginthread(sin_ve_server);

How do I destroy this server on the main UNIX code exit?
(A "Copy|Paste"able example is VERY welcome!)

Tony.

11

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opsfsxouq6o93ri4@mobile.wst.quantum.ru…

On Tue, 12 Oct 2004 18:22:26 -0400, Mario Charest
nowheretobefound@8thdimension.com> > wrote:

Now I have to find a way to run it as the second thread.
_beginthread( main… )

You will have to change main arguments since a thread only takes one
pointer. You will also have to deal with thread termination.

I think I’ll comment out all printf’s and change main there to “void
main(void)”.

It can’t be called main since your UNIX code will also have a main :wink:

By the way, should I give this server a name of it’s own?

If it’s a thread it will have the same name as the UNIX program.

_beginthread(sin_ve_server);

How do I destroy this server on the main UNIX code exit?
(A "Copy|Paste"able example is VERY welcome!)



Tony.

12

This is what I learn at:

#include <errno.h>
#include <stdio.h>
#include <conio.h>
#include <sys/kernel.h>
#include <sys/psinfo.h>
#include <sys/sys_msg.h>
#include <process.h>

#define MY_NAME “myname”
#define MY_VERSION 100
#define MY_LETTER ‘A’

#define STACK_SIZE 8192
#ifdef 386
#define FAR
#else
#define FAR __far
#endif

int let_it_run;

void FAR sin_ve_server( void FAR *parm) {

static const struct _sysmsg_version_reply ver = {
MY_NAME,
DATE,
MY_VERSION,
MY_LETTER
};

struct _sysmsg_hdr_reply rhdr;
struct _sysmsg_hdr shdr;
struct _mxfer_entry rmx[2];
pid_t pid;
int rc;

rc = qnx_pflags(_PPF_SERVER, _PPF_SERVER, 0, 0);
if (rc == -1) {
perror(“qnx_pflags failed”);
_endthread();
}

while ( let_it_run ) {
pid = Receive(0, &shdr, sizeof(shdr));
if (pid == (pid_t)-1) {
perror(“Receive failed”);
break;
}

switch (shdr.type) {
case _SYSMSG :
switch (shdr.subtype) {
case _SYSMSG_SUBTYPE_VERSION :
/* recv system version msg */
rhdr.status = 0;
_setmx(&rmx[0], &rhdr, sizeof(rhdr));
_setmx(&rmx[1], &ver, sizeof(ver));
Replymx(pid, 2, rmx);
break;

default :
/* recv unknown system msg */
rhdr.status = ENOSYS;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
break;

default :
/* recv unknown msg */
rhdr.status = EINVAL;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
}
_endthread();
}

void main() {

int tid;

let_it_run = 1;

tid = _beginthread( sin_ve_server, NULL, STACK_SIZE, NULL );
if ( tid < 0 ) {
perror("_beginthread() failed");
exit( 1 );
}
printf(“sin_version thread is launched. Press a key.\n”);
getch();

let_it_run = 0;

exit( 0 );
}


As was said I see the two instances of the process in “sin” list and one in “sin ve” list.

The thread stays even after the main has exited. I had to use “let_it_run” flag to controll the thread’s existence.

Is it possible to put “tid” to any use when trying to stop|kill the thread?

What makes me wonder is that it takes one extra system message (generated by “sin ve” request) to unload the thread after the main code has exited. I do understand why it does not notice let_it_run flag change immediatelly - the thread is Receive-blocked. But I thought there are lots of system messages propagate through the system every second!

Tony.

13

“Tony” <mts.spb.suxx@mail.ru> wrote in message
news:opsftlglmio93ri4@mobile.wst.quantum.ru…

This is what I learn at:

#include <errno.h
#include <stdio.h
#include <conio.h
#include <sys/kernel.h
#include <sys/psinfo.h
#include <sys/sys_msg.h
#include <process.h

#define MY_NAME “myname”
#define MY_VERSION 100
#define MY_LETTER ‘A’

#define STACK_SIZE 8192
#ifdef 386
#define FAR
#else
#define FAR __far
#endif

int let_it_run;

void FAR sin_ve_server( void FAR *parm) {

static const struct _sysmsg_version_reply ver = {
MY_NAME,
DATE,
MY_VERSION,
MY_LETTER
};

struct _sysmsg_hdr_reply rhdr;
struct _sysmsg_hdr shdr;
struct _mxfer_entry rmx[2];
pid_t pid;
int rc;

rc = qnx_pflags(_PPF_SERVER, _PPF_SERVER, 0, 0);
if (rc == -1) {
perror(“qnx_pflags failed”);
_endthread();
}

while ( let_it_run ) {
pid = Receive(0, &shdr, sizeof(shdr));
if (pid == (pid_t)-1) {
perror(“Receive failed”);
break;
}

switch (shdr.type) {
case _SYSMSG :
switch (shdr.subtype) {
case _SYSMSG_SUBTYPE_VERSION :
/* recv system version msg */
rhdr.status = 0;
_setmx(&rmx[0], &rhdr, sizeof(rhdr));
_setmx(&rmx[1], &ver, sizeof(ver));
Replymx(pid, 2, rmx);
break;

default :
/* recv unknown system msg */
rhdr.status = ENOSYS;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
break;

default :
/* recv unknown msg */
rhdr.status = EINVAL;
Reply(pid, &rhdr, sizeof(rhdr));
break;
}
}
_endthread();
}

void main() {

int tid;

let_it_run = 1;

tid = _beginthread( sin_ve_server, NULL, STACK_SIZE, NULL );
if ( tid < 0 ) {
perror("_beginthread() failed");
exit( 1 );
}
printf(“sin_version thread is launched. Press a key.\n”);
getch();

let_it_run = 0;

exit( 0 );
}


As was said I see the two instances of the process in “sin” list and one
in “sin ve” list.

The thread stays even after the main has exited. I had to use “let_it_run”
flag to controll the thread’s existence.

Is it possible to put “tid” to any use when trying to stop|kill the
thread?

Yes, the tid is infact a pid.

What makes me wonder is that it takes one extra system message (generated
by “sin ve” request) to unload the thread after the main code has exited.
I do understand why it does not notice let_it_run flag change
immediatelly - the thread is Receive-blocked. But I thought there are lots
of system messages propagate through the system every second!

No you will only get message, for death of program (being normal or not) and
sin ver. There may be others but that’s all I can think of at the moment.

After let_it_run = 0, you should wait till the thread has terminted before
calling exit(),

\

Tony.

14

Tony <mts.spb.suxx@mail.ru> wrote:

Is it possible to put “tid” to any use when trying to stop|kill
the thread?

The “tid” just happens to be the pid of the child.

kill(tid, SIGTERM);

would work nicely.

What makes me wonder is that it takes one extra system message
(generated by “sin ve” request) to unload the thread after the
main code has exited. I do understand why it does not notice
let_it_run flag change immediatelly - the thread is Receive-blocked.
But I thought there are lots of system messages propagate through
the system every second!

Well, there may be different “system” messages flying around, depending
on how you define a “system” message, but they are generally each sent
to a specific server, rather than just randomly flying around. So,
you won’t get all that many of them.

-David

David Gibbs
QNX Training Services
dagibbs@qnx.com

15

On 13 Oct 2004 19:08:56 GMT, David Gibbs <dagibbs@qnx.com> wrote:

Well, there may be different “system” messages flying around, depending
on how you define a “system” message, but they are generally each sent
to a specific server, rather than just randomly flying around. So,
you won’t get all that many of them.
I thought they are a sort of broadcasted to all the subscribers…

Should I wait for anything in the main code after I did “kill(tid, SIGQUIT)”?

Tony.

16

Tony wrote:

Should I wait for anything in the main code after I did “kill(tid,
SIGQUIT)”?

Not really. You could do a waitpid(), but since you’re about to exit
anyway, there’s no point.

BTW I suggest a SIGTERM. A SIGQUIT will cause a core dump if dumper is
running.