Well I thought I’d post this one in case it is familiar to some others
here - though I don’t expect it to be.
I have a photon app that creates a pipe, forks, the child makes a system
call and redirects (dup) its stdout to the pipe, and the parent reads
and displays the output by inserting it into a multitext window.
Now this works fine on Qnx4, but on the RTP it only works about 95% of
the time.
In some cases the system call is invoking an RSH call to a Linux box to
get e.g. a “ps -A” listing. In these cases the rsh hangs after
transmitting 1523 bytes or 3072 bytes consistently for two of the
examples I run (i.e. each example hangs at the same point each time)
(and some other rsh commands to linux/qnx boxes work)
But if I manually capture the output by doing the rsh on the command
line and piping to a file, then starting my photon-app and making the
system call ‘cat’ to that file it works fine.
Even if my system call is like this system("rsh -l user remotehost ps -A
/tmp/cap") the file stops getting data at exactly the same point - i.e.
prematurely.
I have an identical non-photon app that works fine with the exact same
command. (it does all the same pipe/fork/dup/etc)
I tried changing the system call to an execvp (the child exits
afterwards either way) but no improvement at all.
So, it is the photon app that has difficulty with the ‘rsh’ command.
I have seen issues in the past where e.g. an rsh command kicks of an app
on the remote side and never closes its pipe as the app may generate
output, but this is not the case here.
I did wonder if the delay between kicking the command off and reading
from the pipe (set to 10ms with a photon-widget-timer) was enough to
fill the pipe and stop it, but that is not the case as redirecting it to
a file within the system call - or even /dev/null (and stderr too) still
hangs it.
I am a little dubious now of my dup2 call - though it worked fine on
QNX4 and on Linux, under neutrino it closes stdout or something - i
added fprintf(stdout,… stuff and it didn’t go over the pipe, but
changing to stderr did - bizzare!!
heres a snip of my code anyway
if( pipe( fd ) == -1 ) {
perror( “pipe” );
exit( EXIT_FAILURE );
}
if( ( pid = fork() ) == -1 ) {
perror( “fork” );
exit( EXIT_FAILURE );
}
if( pid == 0 ) {
/* This is the child process.
- Move write end of the pipe to stdout (1),
- close any extraneous file descriptors,
- then use exec to ‘become’ the command.
/
dup2( fd[1], STDOUT_FILENO );
dup2( STDOUT_FILENO, STDERR_FILENO);
close( fd[0] );
execvp( argv[0], argv );
/ This can only happen if exec fails; print message - and exit.
/
perror( argv[0] );
exit( EXIT_FAILURE );
} else {
/ This is the parent process. - Remove extraneous file descriptors,
- read descriptor 0, write to screen,
- close pipe, and wait for child to die.
/
close( fd[1] );
dup2( fd[0], STDIN_FILENO ); / move pipe to stdin */
writeInputToFiles();
close( fd[0] );
}
Anyone seen anything similar with rsh or phab?
cheers
Lance
Lance Roberts
www.2000solved.com
Sent via Deja.com http://www.deja.com/
Before you buy.