Thanks Stuart,
I was trying to avoid using ConnectAttach to attach to queues between
processes. The problem is making the server PID available to the client
using ConnectAttach. I settled on name_attach/name_open, because we could
put the server name in a defines file and then all have access to the name
at compile time.
Depending on what the tech wizards at QSSL tell me as a result of my
problem report, I may just have to spawn a thread, pthread style, and have
that thread start and stop the daemon. If you have any other suggestions
about the problem, I’d welcome hearing them.
Sincerely,
David Kuechenmeister
“Stuart Harding” <stuart@intellidesign.com.au> wrote in message
news:avipru$2dk$1@inn.qnx.com…
Hi David.
We have just solved a similar problem where if we called ConnectAttach()
before a spawnlp, both the old process and new process would block. The
problem was where we specified _NTO_SIDE_CHANNEL in the ConnectAttach()
call. _NTO_SIDE_CHANNEL is not a flag, it is an index, and should be
placed
in the index argument of the ConnectAttach, as specified in the
documentation for ConnectAttach.
Cheers,
Stuart Harding
“David Kuechenmeister” <> david.kuechenmeister@viasat.com> > wrote in message
news:au9m0h$pr8$> 1@inn.qnx.com> …
I used name_open and name_attach instead of ChannelCreate and
ConnectAttach.
Those calls seemed more useful in a mult-process environment. I still
don’t
see an obvious method to pass the pid and channel ID from the process
calling ChannelCreate to the process that wants to use ConnectAttach to
send
a message to the first process. Using a defined set of names for the
servers
made that task much easier, unnecessary in fact. That’s a different
matter,
however.
Will name_attach give me the same kind of behavior that you described
for
ConnectAttach? Is there a better spawn call that will let me control
that
behavior?
Thanks,
.dk
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:au809l$1ba$> 2@nntp.qnx.com> …
Do you have any ConnectAttach() calls in your larger program? If so,
are you passing in the _NTO_SIDE_CHANNEL as required and as the right
parameter? Generally when you spawn a process and it goes SEND
blocked
on the parent it is due to a connection being made in the file
descriptor
space and the child process is attempting to DUP the fd.
chris
David Kuechenmeister <> david.kuechenmeister@viasat.com> > wrote:
I have a couple functions that spawn or kill our embedded ntpd
process
on
demand. The spawn function is pretty simple, just
synch_stat = spawnlp(P_NOWAITO,
“/usr/sbin/ntpd”,
“/usr/sbin/ntpd”,
“-g”,
“-l”,
“/home/servo/log/ntp.log”,
“-p”,
“/home/servo/log/ntp.pid”,
NULL);
This runs fine in a simple executable, but when I put it into the
process
that receives and parses the TCP/IP message from the operator’s
console,
the
ntpd process send blocks on the parent process. From what I
understand,
SEND
means that ntpd is trying to send a message to the parent, but there
is
nothing to receive the message.
The simple executable is nothing more than main(){spawnlp();}. There
isn’t
anything there to receive a message, so I must not fully understand
why
ntpd
send blocks in the user-interface application.
Thanks for any advice or insight into this problem.
Regards,
Dave Kuechenmeister
\
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I
get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\