Robert Muil <email@example.com> wrote:
I have run aground on strange behaviour in QNX 6.2.1.
system() hangs after a call to select_attach().
There appears to be a conflict with the system() and select_attach()
function calls. I can use system() to execute arbitrary commands in my code
at any point up to where I use select_attach() to attach a socket file
descriptor to the dispatch layer. After the call to select_attach(), any
call to system() hangs indefinitely (or until I send it Ctrl-C).
I have tried setting the FD_CLOEXEC flag on the socket file descriptor, to
make sure it was not a problem with the new process inheriting the socket.
This did not help.
I tried a little test of this under 6.3.0 (don’t have a convenient
6.2.1 system) using stdin, and did not have any problems.
- If you do a select_attach() for fd 0 (stdin) for EXCEPT conditions, does
- When the program is in this state, what state is the thread in? Can you
get the output from “pidin” for your process?
- system() is a horrible, evil, inefficient monster of a function call.
system() will run a sh (which will fully set itself up, including possibly
interpreting and running local setup scripts), which will then parse the
command line, and usually run another program. In most cases, the other
program is what you wanted to run, not the shell – and the shell is just
overhead. (Note: system is convenient, though.) system() will, then,
wait for the shell to finish & exit, and the shell will have done the same
for the command it ran. If you are just doing something like:
system("/path/to/other_command -a -v -g argument1 argument2"); it is far
more efficient to call spawnl(), and avoid the shell in the middle. You
can break it down even further, by calling spawnl(P_NOWAIT) then doing the
waitpid() yourself. This breaking down of steps could, actually, help to
figure out what step is going wrong as well.
QNX Training Services
Please followup in this newsgroup if you have further questions.