signal

hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?
  2. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks

The more QNX’y (and, IMHO, better) way is to have your parent process attach
a prefix and have each child open the prefix. Then, whenever a child dies,
the OS will send _IO_CLOSE to your parent.

See functions qnx_prefix* and qnx_fd_attach and header sys/io_msgs.h.

Itzik Nesher wrote:

hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?
  2. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks

hi,

  1. Is it possible to do it from script ? my child process is script.
  2. Which operations allowed inside the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks,

Dean Douthat wrote:

The more QNX’y (and, IMHO, better) way is to have your parent process attach
a prefix and have each child open the prefix. Then, whenever a child dies,
the OS will send _IO_CLOSE to your parent.

See functions qnx_prefix* and qnx_fd_attach and header sys/io_msgs.h.

Itzik Nesher wrote:

hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?
  2. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks

One other option is to turn on system flags so that
you get obituaries. You will get a death message for
every process that dies, and vid that detaches, so you
will have to compare them with a list of child pid’s.


Previously, Itzik Nesher wrote in qdn.public.qnx4:

hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?
  2. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks


Mitchell Schoenbrun --------- maschoen@pobox.com

Thanks for your help,

Soory, but your answer is very general and I did’t understood which system
flag and what is the value of it.
Which death message you get ? which functions I should use ?
How can I get child list ?

Thanks,

Mitchell Schoenbrun wrote:

One other option is to turn on system flags so that
you get obituaries. You will get a death message for
every process that dies, and vid that detaches, so you
will have to compare them with a list of child pid’s.

Previously, Itzik Nesher wrote in qdn.public.qnx4:
hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?
  2. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks


\

Mitchell Schoenbrun --------- > maschoen@pobox.com

Yes, you can open a file from a scipt by using redirection in the shell. To open
an attached prefix “file”, just do:

3< name_of_parent_attached_prefix

Yes, Trigger is signal safe. There is a table of all c functions showing whether
they are safe for interrupts, signals or threads under the c library reference
summary accessed by clicking on function safety (or something like that).

Itzik Nesher wrote:

hi,

  1. Is it possible to do it from script ? my child process is script.
  2. Which operations allowed inside the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks,

Dean Douthat wrote:

The more QNX’y (and, IMHO, better) way is to have your parent process attach
a prefix and have each child open the prefix. Then, whenever a child dies,
the OS will send _IO_CLOSE to your parent.

See functions qnx_prefix* and qnx_fd_attach and header sys/io_msgs.h.

Itzik Nesher wrote:

hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?
  2. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

Thanks

Mitchell Schoenbrun <maschoen@pobox.com> wrote:

One other option is to turn on system flags so that
you get obituaries. You will get a death message for
every process that dies, and vid that detaches, so you
will have to compare them with a list of child pid’s.

This is not recommended – it is a holdover from the QNX2
way of doing things. There can be dangerous side-effects
from doing this.

-David


Previously, Itzik Nesher wrote in qdn.public.qnx4:
hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?

If you want to do the work of being an IO-manager you can use the
IO_CLOSE message stuff others have suggested. It probably isn’t better.

In fact, getting and handling SIGCHLD – so only calling one of the
wait() family of functions when you know there is something to wait for –
is a good and general way of handling this.

  1. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function ?

It is quite safe to call Trigger(proxyId) from inside the signal function.

Often, people will mask and unmask the SIGCHLD signal as well – only
unmasking it at their blocking point – usually a Receive() call.

sigprocmask ( ) /* unblock SIGCHLD /
Receive()
sigprocmask( ) /
block SIGCHLD */

/* check return from Receive, is it -1, is it proxy, is it message, etc. */

And Trigger() a “child death” proxy in the signal handler, preventing race
conditions.

-David

QNX Training Services
dagibbs@qnx.com

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:94ptja$bpr$2@nntp.qnx.com

Mitchell Schoenbrun <> maschoen@pobox.com> > wrote:
One other option is to turn on system flags so that
you get obituaries. You will get a death message for
every process that dies, and vid that detaches, so you
will have to compare them with a list of child pid’s.

This is not recommended – it is a holdover from the QNX2
way of doing things. There can be dangerous side-effects
from doing this.

you mean that handling system notification about process death under
qnx4 is potentially dangerous ? what kind of side effects can be ? still
we extensivly use this system message in order to be sure to free allocated
resources and all seems to be quite fine.

Previously, Itzik Nesher wrote in qdn.public.qnx4:
hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?

If you want to do the work of being an IO-manager you can use the
IO_CLOSE message stuff others have suggested. It probably isn’t better.

In fact, getting and handling SIGCHLD – so only calling one of the
wait() family of functions when you know there is something to wait for –
is a good and general way of handling this.

  1. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function
    ?

It is quite safe to call Trigger(proxyId) from inside the signal function.

Often, people will mask and unmask the SIGCHLD signal as well – only
unmasking it at their blocking point – usually a Receive() call.

sigprocmask ( ) /* unblock SIGCHLD /
Receive()
sigprocmask( ) /
block SIGCHLD */

/* check return from Receive, is it -1, is it proxy, is it message, etc.
*/

And Trigger() a “child death” proxy in the signal handler, preventing race
conditions.

-David

QNX Training Services
dagibbs@qnx.com

// wbr


Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit www.novosoft-us.com

To make sure we’re on the same page: Are you talking about qnx_pflags and
‘PPF_INFORM’ to request death messages? or are you referring to something else?

KenR

“Ian M. Zagorskih” wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:94ptja$bpr$> 2@nntp.qnx.com> …
Mitchell Schoenbrun <> maschoen@pobox.com> > wrote:
One other option is to turn on system flags so that
you get obituaries. You will get a death message for
every process that dies, and vid that detaches, so you
will have to compare them with a list of child pid’s.

This is not recommended – it is a holdover from the QNX2
way of doing things. There can be dangerous side-effects
from doing this.

you mean that handling system notification about process death under
qnx4 is potentially dangerous ? what kind of side effects can be ? still
we extensivly use this system message in order to be sure to free allocated
resources and all seems to be quite fine.



Previously, Itzik Nesher wrote in qdn.public.qnx4:
hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend state in
my parent process)

  1. Is someone have better way to catch it with out waiting for child
    process exit ?

If you want to do the work of being an IO-manager you can use the
IO_CLOSE message stuff others have suggested. It probably isn’t better.

In fact, getting and handling SIGCHLD – so only calling one of the
wait() family of functions when you know there is something to wait for –
is a good and general way of handling this.

  1. Which operations allowed in the signal function void sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the function
    ?

It is quite safe to call Trigger(proxyId) from inside the signal function.

Often, people will mask and unmask the SIGCHLD signal as well – only
unmasking it at their blocking point – usually a Receive() call.

sigprocmask ( ) /* unblock SIGCHLD /
Receive()
sigprocmask( ) /
block SIGCHLD */

/* check return from Receive, is it -1, is it proxy, is it message, etc.
*/

And Trigger() a “child death” proxy in the signal handler, preventing race
conditions.

-David

QNX Training Services
dagibbs@qnx.com

// wbr


Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: > ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit > www.novosoft-us.com

“rectech” <rectech@iname.com> wrote in message
news:3A70B579.9C4ABE33@iname.com

To make sure we’re on the same page: Are you talking about qnx_pflags and
‘PPF_INFORM’ to request death messages? or are you referring to something
else?

KenR

exactly this flag and system message with subtype _SYSMSG_SUBTYPE_DEATH.
my code usually looks like smth:


#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <sys/types.h>
#include <sys/kernel.h>
#include <sys/psinfo.h>
#include <sys/sys_msg.h>

#define SERVER_FLAGS (_PPF_SERVER | _PPF_INFORM)

static int old_pflags;
static int exitsigno;

static int init_server(void) {
int result;
result = -1;
if ((old_pflags = qnx_pflags(~0L,SERVER_FLAGS,NULL,NULL)) != -1) {
/* … *.
result = 0;
}
return result;
}

static void deinit_server(void) {
/* … */
qnx_pflags(~0L,old_pflags,NULL,NULL);
}

int main(int argc, char argv[]) {
struct _sysmsg_hdr_reply reply_msg;
struct _sysmsg_hdr receive_msg;
pid_t pid;
if (init_server() != -1) {
for (exitsigno = 0; exitsigno == 0; ) {
memset(&receive_msg,0,sizeof(receive_msg));
pid = Receive(0,&receive_msg,sizeof(receive_msg));
if (pid != -1) {
if (check_proxy_pids(pid) != -1) {
/
handle proxies here /
/
/
/
no reply is needed on proxy event /
} else {
/
handle message from another process /
if (receive_msg.type == _SYSMSG) {
memset(&reply_msg,0,sizeof(reply_msg));
switch (receive_msg.subtype ) {
case _SYSMSG_SUBTYPE_DEATH :
/
kernel notification about process
death with received pid /
/
handle process death here /
/
… */
reply_msg.status = EOK;

Reply(pid,&reply_msg,sizeof(reply_msg));
break;
case _SYSMSG_SUBTYPE_VERSION :
/* reply with server version
structure /
/
… */
break;
default :
reply_msg.status = ENOSYS;

Reply(pid,&reply_msg,sizeof(reply_msg));
break;
}
} else {
/* handle usre defined messages /
/
/
}
}
} else {
/
handle receive errors /
/
… */
}
}
deinit_server();
}
}

\

“Ian M. Zagorskih” wrote:

“David Gibbs” <> dagibbs@qnx.com> > wrote in message
news:94ptja$bpr$> 2@nntp.qnx.com> …
Mitchell Schoenbrun <> maschoen@pobox.com> > wrote:
One other option is to turn on system flags so that
you get obituaries. You will get a death message for
every process that dies, and vid that detaches, so you
will have to compare them with a list of child pid’s.

This is not recommended – it is a holdover from the QNX2
way of doing things. There can be dangerous side-effects
from doing this.

you mean that handling system notification about process death under
qnx4 is potentially dangerous ? what kind of side effects can be ? still
we extensivly use this system message in order to be sure to free
allocated
resources and all seems to be quite fine.



Previously, Itzik Nesher wrote in qdn.public.qnx4:
hi,
I’m using signal(SIGCHLD, sigFunc) to catch exit of child process
instead of using wait() ( since I don’t want to be in suspend
state in
my parent process)

  1. Is someone have better way to catch it with out waiting for
    child
    process exit ?

If you want to do the work of being an IO-manager you can use the
IO_CLOSE message stuff others have suggested. It probably isn’t
better.

In fact, getting and handling SIGCHLD – so only calling one of the
wait() family of functions when you know there is something to wait
for –
is a good and general way of handling this.

  1. Which operations allowed in the signal function void
    sigFunc(int
    sig_num) ?
    is it safe to call “Trigger(proxyId)” function inside the
    function
    ?

It is quite safe to call Trigger(proxyId) from inside the signal
function.

Often, people will mask and unmask the SIGCHLD signal as well – only
unmasking it at their blocking point – usually a Receive() call.

sigprocmask ( ) /* unblock SIGCHLD /
Receive()
sigprocmask( ) /
block SIGCHLD */

/* check return from Receive, is it -1, is it proxy, is it message,
etc.
*/

And Trigger() a “child death” proxy in the signal handler, preventing
race
conditions.

-David

QNX Training Services
dagibbs@qnx.com


Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit www.novosoft-us.com

Ian M. Zagorskih <ianzag@novosoft.ru> wrote:

“rectech” <> rectech@iname.com> > wrote in message
news:> 3A70B579.9C4ABE33@iname.com> …
To make sure we’re on the same page: Are you talking about qnx_pflags and
‘PPF_INFORM’ to request death messages? or are you referring to something
else?

KenR

exactly this flag and system message with subtype _SYSMSG_SUBTYPE_DEATH.
my code usually looks like smth:

The process creation/termination “thread” in the Process manager is
SEND/REPLY blocked on your server until you reply to it. This will
prevent/delay process creation/termination.

Also, once you register for DEATH messages, don’t do any new process
creation, as this could result in a deadlock if a termination happens
when you’re trying to do a creation.

switch (receive_msg.subtype ) {
case _SYSMSG_SUBTYPE_DEATH :
/* kernel notification about process
death with received pid /
/
handle process death here /
Make sure this handling is fast.
/
… */
reply_msg.status = EOK;

Reply(pid,&reply_msg,sizeof(reply_msg));

Or move it to here, after you’ve replied to Proc.

-David

QNX Training Services
dagibbs@qnx.com

thank you david, your reply gives me several very interesting hints :slight_smile:

“David Gibbs” <dagibbs@qnx.com> wrote in message
news:954qtq$lvd$1@nntp.qnx.com

Ian M. Zagorskih <> ianzag@novosoft.ru> > wrote:

“rectech” <> rectech@iname.com> > wrote in message
news:> 3A70B579.9C4ABE33@iname.com> …
To make sure we’re on the same page: Are you talking about qnx_pflags
and
‘PPF_INFORM’ to request death messages? or are you referring to
something
else?

KenR

exactly this flag and system message with subtype _SYSMSG_SUBTYPE_DEATH.
my code usually looks like smth:

The process creation/termination “thread” in the Process manager is
SEND/REPLY blocked on your server until you reply to it. This will
prevent/delay process creation/termination.

Also, once you register for DEATH messages, don’t do any new process
creation, as this could result in a deadlock if a termination happens
when you’re trying to do a creation.

switch (receive_msg.subtype ) {
case _SYSMSG_SUBTYPE_DEATH :
/* kernel notification about
process
death with received pid /
/
handle process death here /
Make sure this handling is fast.
/
… */
reply_msg.status = EOK;

Reply(pid,&reply_msg,sizeof(reply_msg));

Or move it to here, after you’ve replied to Proc.

-David

QNX Training Services
dagibbs@qnx.com

// wbr


Ian Zagorskih
Novosoft CyBearNet Department
Custom software development and web design since 1992
E-mail: ianzag@novosoft.ru
Phone: +7 (3832) 39-72-60, 39-72-61
Fax: +7 (3832) 39-63-58
For more visit www.novosoft-us.com