launching of processes occur not in the start order.

[jean-jacques]

I am testing a little application (deadwood-2 from development tree of maradns). One of the regressions test consist to check what happen in case that to many DNS query are send to the server. Under Solaris ans Linux (in a VirtualBox), the test fails often. 8 query process are started in background in order to create the overload situation. After the processes are started a query process is started in foreground. Mostly the result is not as expected. The reason is that the foregrounf process is often started before all background processe are started. I have verified this we a few printf into the sources ans also inserted a sleep into the test script. Wit the sleep inserted before launching the foreground process all work fine, without it the test don't mostly not work as expected

[Frank Mehnert]

Do I understand you right that you are trying to start multiple applications at the same time and the order the applications are actually started is not as expected? Then I don't think this is a bug since the timing behavior of a virtualized guest is different from real hardware.

[jean-jacques]

Right, I start 8 processes in background and then the test process in foreground. I think that the timing behaviour of a virtual machine should not be very different of the timing of a real machine. If the background processes are p1 to p8 and the test process is PT, I would have for example the order p1, p2,p3,p4, PT, p5,p6,p7,p8. An other order as P1,...P8, PT can't be acceptable. For example if I look ate the start sequence of U*X systems, some processes are dependent of other (eg network related processes should not be started before the network is started).

[Frank Mehnert]

If there are dependencies between processes then you have to ensure these dependencies by some kind of information flow between these processes to achieve synchronization and not by timing. I'm quite sure that you will observe a different starting order on real hardware if you start a high CPU load and/or a high disk load in parallel to your test applications.

[jean-jacques]

The start order should be always the same. The problem is that some processes may be much slower (timeslice to small) so that the apparent start order seem to be changed.

[Frank Mehnert]

Question is if the start order is really different. How do you actually check the starting order? By looking for some output via printf?

[jean-jacques]

I had a fews printf within the server in order to see that some events appeared. I have solved the problem with a sleep before starting the the last test process. With this little modification I had no more problems, the background processes had enough time in order to start and send a query to the server. This had confirmed the analyse of the few print output. Where is stated that the toiming behaviour of VirtualBox differ from an real hardware ?

[Frank Mehnert]

The timing behavior of every virtual machine is different from real hardware. And the timing behavior between real hardware is different as well, the thing is that you most often will not notice the difference. Think about a virtual machine of a hardware where the execution time of some instructions is one (more even several) order(s) of magnitude higher than on real hardware. But the execution time of the most instructions is similar to real hardware. Virtualization of a process start needs usually much more effort than virtualization of a running process.

[jean-jacques]

OK this is not a bug this is a feature. I was meaning that the start of each prozess will not differ very much from the real hardware. May be that on a dual core machine the timing is very different from a single core machine and that this was one of the reason for the apparently delayed start of processes.

[Frank Mehnert]

Sorry, this feature request cannot be solved, at least not explicitly.