Qnet and select_attach() problems


I’m developing a program that opens up a file descriptor of a resource manager and then attaches a function to it using select_attach() to process data once it becomes available.

I have two QNX machines. One running 6.3.0 (A) and the other is running 6.2.1 (B). I have a resource manager running on B.

When I execute my program on B it connects to the resource manager and reads data in when it becomes available without any problem.

The problem starts when I run the program on A opening with “/net/b/dev/handle/data/”. It connects fine, but will only reads in the data once. If new data becomes available, the handler function isn’t called.

Qnet is working fine, I can “ls /net/b/home/” without any problems. Both machines are using npm-qnet-compat.so

When I do a pidin, the process blocks in RECEIVE on both machines. The only difference is that priority on A is: 10r and B is: 10o. But that shouldn’t make a difference as “o” (other) is implemented as “r” (round robin) in QNX.

It seems to me that the process gets stuck in a RECEIVE state and doesn’t hear any notification signals to “wake up”. On way around it is to put while(1) loop inside the handler function to keep reading the data. Its not ideal, but it works!!!

If anyone has any suggestions on this issue, I’d really be grateful.



There would seem to be two possible reasons for the problem, 1) an incompatibility between the two OS’s, or a bug in one of them, 2) a bug in using this feature over the network. If possible, I’d test this with two 6.3 and/or two 6.2.1 machines, to find out which problem it is. In the case of 6.3, there are two QNET versions you can try, the 6.2.1 compatible version, and the newer version.

Thanks for your suggestions! That makes sense alright.

Unfortunately, I only have the two machines. So I can’t really test it with a third. There’s quite alot of code written on the 6.2.1 (its a robot) and I’m nervous about upgrading it because I don’t want to break anything.

Its strange how the handler function gets called once, but never again!