spawn problem over qnet

GENERAL Help
1

I have a problem with spawn over qnet in qnx 6.2.1 and 6.3. I fill all neded spawn flags and then I am calling spawn to place some resource manager on another node. The problem is that this resource manager process don’t place file descriptor in wright place (on the node where process is registered) or even don’t see some pci device’s it is working with. If I use chroot("/net/dasda"); before there are different problems: opening of file descriptor from anoher node is unsucsesfull and second calling of spawn is also unsecsesfull. If samonce can help me with some working code i will be pleased.

Thanks

2

If you spawn() the manage to a node called “remote_node”, do this before you spawn().

chroot("/net/remote_node");

This should give you the result you expected.

3

Thanks for your fast advice. Unfortunetly problem is a liitle bit complicated and now I try to describe it. I try to spawn resource manager form node 1 to node 2. so I call:

chroot("/net/node2");
spawn("…

but then I want to return to prevoius location to make some ather job on the first node (for example to connect to this resource manager and make some locall spawn). Callling

chroot("/net/node1");

is intiuitive but it doesnt work because after second:

chroot("/net/node2");
spawn("…

resource manager doesn’t start fine. The symptom is that path become longer and longer. I can’t change it in 6.3.0.

I found solution in 6.2.1

chroot("/net/node2");
spawn("…
chroot("…/…/…/…/…/…/…/"); //or longer

it looks terrible but it worked. I could call this section again and again and everything worked fine. Unfortunetly in 6.3.0 it stoped. The way spawn behave seems to be enormous QNX bug, or I am wrong ?? Maybe someone from QNX devolopers will think about it and fix it. After dooing great job with gns mechanism in 6.2.1 to 6.3.0 migration, this is maybe the last major qnet bug left.

Please let me know if there is other technique of making multiple network spawn in code of one process. I started to thing about cascade spawn to spawn locally and then globally (quite complicated) or using "on -f …’ but what about pid of child then ??

Thanks

4

No, spawn() is fine, chroot() is messy :slight_smile: With every thing in QNX is a path name,
chroot() is more complicate.

After chroot() to another node, your probably no permission to chroot() back. (the fact you can chroot back to orignal node in 6.2, is actually a
bug).

I can think of several work arround, but no one is the best.

  1. you can fork() and let client chroot()/spawn(), report back the child pid. This
    will not work if your loading program is multi-threaded.

  2. spawn(“on -f …”), you won’t have child’s pid. You can of cause as child to
    write his pid to somewhere, /var/run/child.pid maybe, and go open that file
    to get the pid.

  3. If you have a “manager” exist on all nodes, you can instead of spawn remote,
    just message pass to remote manager and let him spawn().

5

Ok thanks, I understand proposed solutions, but I think that this is complicated and spawn schould done all that job in further QNX versions.