[SSI-users] rfork bug ?

[Maxime R. <max...@th...>]

Hi,

I wrote a little piece of code (derivating from an unstable OpenMosix
in fact) for testing an openssi cluster. The program tests both SysV 
shared memory migration, semaphores, and (of course) process migration. 
Look at attachement.

It does work very well when I use fork and the automatic load balancer,
but it seems the rfork doesn't do what it should.
My cluster has 2 nodes, so rfork chooses between node nr 2 and 3 (I have no
node nr 1 yet).

See the output :
airmax@jack:~/adapt/stresstest/shm_test% ./shm_test 1
Running test with 1 iterates
Master pid: 135875 (is also a writer)

--> PID of parent (on node 2)

Test on 1 iterates
Writer pid: 135876

--> first fork, the new process with PID 135876 is now on node 3.

135876 : semaphore lock
135876 (node 2): shared memory is: aaaaaaaaaabbbbbbbbbbcccccccccc
135876 : semaphore unlock

Ok, the new child does its stupid semaphores uses...

Writer pid: 135875

--> second fork, with rfork(2). 
So, if printing "Writer pid it is son". Yes, but it has the PID
of his parents, and the parents seems to be lost...

135875 : semaphore lock
135875 (node 2): shared memory is: aaaaaaaaaabbbbbbbbbbcccccccccc
135875 : semaphore unlock

Bug or feature ?

According to the manpage, it is a bug.


-- 
Maxime Ritter