obtaining process/thread status

bridged with qdn.public.qnxrtp.applications
Post Reply
Nnamdi Kohn

obtaining process/thread status

Post by Nnamdi Kohn » Fri Jun 28, 2002 1:32 pm

Hi,
in order to be able to build stable applications using message passing, I
would like to test if a process/thread is actually present in the system and
if this process/thread is ready to receive messages (receive blocking
status) from an other process/thread.
Are there QNX operating system functions (in C) that help me figure out the
existence and status of processes/threads? Or are there other possibilities
to stabilize the communication tasks?

Regards.

Nnamdi

ed1k

Re: obtaining process/thread status

Post by ed1k » Fri Jul 05, 2002 10:29 am

Nnamdi Kohn <nnamdi.kohn@tu-bs.de> wrote in article <afhock$3dn$1@inn.qnx.com>...
Hi,
in order to be able to build stable applications using message passing, I
would like to test if a process/thread is actually present in the system and
if this process/thread is ready to receive messages (receive blocking
status) from an other process/thread.
Are there QNX operating system functions (in C) that help me figure out the
existence and status of processes/threads?
You could look at pidin source at cvs.
--
Eduard.
ed1k at ukr dot net

Or are there other possibilities
to stabilize the communication tasks?

Regards.

Nnamdi


Nnamdi Kohn

Re: obtaining process/thread status

Post by Nnamdi Kohn » Tue Jul 09, 2002 9:38 am

Hi,
in order to be able to build stable applications using message passing,
I
would like to test if a process/thread is actually present in the system
and
if this process/thread is ready to receive messages (receive blocking
status) from an other process/thread.
Are there QNX operating system functions (in C) that help me figure out
the
existence and status of processes/threads?

You could look at pidin source at cvs.
where do I exactly find that source?

are there really NO C-functions to obtain the process/thread status in own
programs?

Regards.

Nnamdi

Xiaodan Tang

Re: obtaining process/thread status

Post by Xiaodan Tang » Tue Jul 09, 2002 2:09 pm

Nnamdi Kohn <nnamdi.kohn@tu-bs.de> wrote:
Hi,
in order to be able to build stable applications using message passing,
I
would like to test if a process/thread is actually present in the system
and
if this process/thread is ready to receive messages (receive blocking
status) from an other process/thread.
Are there QNX operating system functions (in C) that help me figure out
the
existence and status of processes/threads?

You could look at pidin source at cvs.

where do I exactly find that source?

are there really NO C-functions to obtain the process/thread status in own
programs?
if you want to know pid=5/tid=3 is exist or not, send a signal 0
to it is the "posix way" (I think).

However, why do you want to know that (or how you get pid/tid) is
another story. Usually you want to know "is my xyz server exist"?
And that should be done by 1) server "resmgr_attach()/name_attach()",
2) client "open()/name_open()".

-xtang

ed1k

Re: obtaining process/thread status

Post by ed1k » Tue Jul 09, 2002 2:55 pm

Nnamdi Kohn <nnamdi.kohn@tu-bs.de> wrote in article <ageak9$qcb$1@inn.qnx.com>...
where do I exactly find that source?
http://cvs.qnx.com/cgi-bin/cvsweb.cgi/utils/p/pidin/

--
Eduard.
ed1k at ukr dot net

David Gibbs

Re: obtaining process/thread status

Post by David Gibbs » Mon Jul 15, 2002 9:30 pm

Nnamdi Kohn <nnamdi.kohn@tu-bs.de> wrote:
if this process/thread is ready to receive messages (receive blocking
status) from an other process/thread.
Are there QNX operating system functions (in C) that help me figure out
the
existence and status of processes/threads?

You could look at pidin source at cvs.

where do I exactly find that source?
cvs.qnx.com
are there really NO C-functions to obtain the process/thread status in own
programs?
Not NO functions.

But, essentially, from the outside processes are logically a black
box -- they provide some services to you, through interfaces, usually
message based -- but you can't tell if it has one thread inside or
15, and you're not really supposed to be able to tell.

But, of course, for debugging purposes, you often have to look inside
your black boxes -- that is why there are debug APIs that allow you
to do this -- but they are intended for debugging, therefor they may
not be the most convenient way to do what you want. The pidin source
from cvs.qnx.com shows how IT looks inside processes to give you thread
listings.

Now, checking for the existence of processes is something that is more
expected. If you know the pid already -- you can use something like
kill(pid, 0) to test for its existence. If you don't know its pid --
then you get into location issues, how would you locate the pid in
the first place? Usually you need some sort of name resolution mechanism,
and QNX provides one -- the pathname space. Processes that want to be
found, put a name in the pathname space, and process that want to find
them look for that name. There are two primary ways this is done --
resmgr_attach() by resource managers, found with open() or name_attach()
for non-resource managers, found by name_open().

In both case, if the person who has registered a name terminates, that
name will be removed from the pathname space -- so checking for the
existence of their name can be used as a method of checking for the
existence of a process that provides such a service.

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

Nnamdi Kohn

Re: obtaining process/thread status

Post by Nnamdi Kohn » Fri Jul 19, 2002 11:08 am

However, why do you want to know that (or how you get pid/tid) is
another story. Usually you want to know "is my xyz server exist"?
And that should be done by 1) server "resmgr_attach()/name_attach()",
2) client "open()/name_open()".
I want to know that because, like in a middleware, I have a central server
"ORG" that organizes all message-based communication processes between other
clients and servers. This server "ORG" keeps track of the open requests
between all clients and servers. When one of the servers or clients is not
in a RECEIVE BLOCKED state, and the server "ORG" tries to complete a
communication process, "ORG" will be blocked and thus not able to service
the other clients and servers. This I want to check, before starting a
communication task in "ORG".

Nnamdi

Nnamdi Kohn

Re: obtaining process/thread status

Post by Nnamdi Kohn » Fri Jul 19, 2002 11:33 am

But, essentially, from the outside processes are logically a black
box -- they provide some services to you, through interfaces, usually
message based -- but you can't tell if it has one thread inside or
15, and you're not really supposed to be able to tell.

But, of course, for debugging purposes, you often have to look inside
your black boxes -- that is why there are debug APIs that allow you
to do this -- but they are intended for debugging, therefor they may
not be the most convenient way to do what you want. The pidin source
from cvs.qnx.com shows how IT looks inside processes to give you thread
listings.

Now, checking for the existence of processes is something that is more
expected. If you know the pid already -- you can use something like
kill(pid, 0) to test for its existence. If you don't know its pid --
then you get into location issues, how would you locate the pid in
the first place? Usually you need some sort of name resolution mechanism,
and QNX provides one -- the pathname space. Processes that want to be
found, put a name in the pathname space, and process that want to find
them look for that name. There are two primary ways this is done --
resmgr_attach() by resource managers, found with open() or name_attach()
for non-resource managers, found by name_open().

In both case, if the person who has registered a name terminates, that
name will be removed from the pathname space -- so checking for the
existence of their name can be used as a method of checking for the
existence of a process that provides such a service.
Thank you, David. I think I understood - especially the black box idea of
QNX and that the user is not really supposed to examine the thread status of
other threads/processes.

Nnamdi

Post Reply

Return to “qdn.public.qnxrtp.applications”