system()/select_attach() conflict

QNX Newsgroups (Archives) comp.os.qnx
1

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.

Robert.

2

Robert Muil <r.muil@crcmining.com.au> 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.

So…

  1. If you do a select_attach() for fd 0 (stdin) for EXCEPT conditions, does
    this happen?
  2. When the program is in this state, what state is the thread in? Can you
    get the output from “pidin” for your process?
  3. 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.

-David

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