I have modified the XFree86 source code configuration files to
Cross compile for SH4 processor.
To use IEEE1394 (FireWire) as communication protocol.
While running a remote X client application from remote 1394 node, Xeyes and xcalc are executed successfully. While starting xterm from remote node it gives the following Error Message:
xterm: Error 29, errno 89: Function not implemented
Reason: spawn: fork () failed
Further analysis showed the error is getting generated from main.c inside /xc/programs/xterm (Line No - 2996) where it calls fork in main function and fork returns -1. QNX documentation shows QNX supports fork call except it is called from a thread. What can be an alternate solution for this problem?
I think fork() must be called prior to creating any additional threads. Is it really the case that in the xterm source threads are created between main() entry point and the call to fork()?
If so then the code must be modified such that it forks before the threads are created or use the spawn() family of functions.
I saw xterm working correctly on QNX. Maybe it happens that it tries to start some program and this doesn’t work over a remote connection.
QNX - X86 - TCP/IP combination worked fine for me as well because there were no thread created before the fork.
We have modified the code to have XFree86 with 1394 protocol support for communication in place of TCP/IP.
fork is getting called after 1394 stack during initialization. I have checked that the stack creates couple of threads during initialization before the fork call.
for spawning the child as separate executable the major problem raising is variables updated by parent does not contain same value in child process and child is terminating.
I think there is is one spawn*() function that has a INHERITANCE structure parameter, which allows you to select which of the parent’s open file descriptors the child should inherit. I must confess that I personally have not used this feature yet but it looks to me that it can help you out.
I guess that some of the variables you want to pass to the child are only available after 1394 stack has initialized. Another possibility would be to set up a dedicated message passing scheme (either MsgSend() or a shared memory region I suggest) that allows the parent to pass these parameters at a time convenient to the programs states.
Otherwise fork() the child and then initialize 1394 stack.
By the way, 1394 support is not available from QSSL directly, and I remember only one company selling a stack that worked on QNX but they discontinued the support. What stack are you using, and is this port available to others as well?
Hi,
right now I’m on business trip and don’t have access to any documentation but I suggest you look up the documentation for spawn(). I guess not all of the parameters may be NULL, or you have to specify an explicit path to the executable. There are many varinats of the spawn() function.