Opened 17 years ago

Closed 17 years ago

#996 closed defect (invalid)

launching of processes occur not in the start order.

Reported by: jean-jacques Owned by:
Component: other Version: VirtualBox 1.5.2
Keywords: start order. Cc: jj.sarton@…
Guest type: other Host type: other


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

Change History (9)

comment:1 by Frank Mehnert, 17 years ago

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.

comment:2 by jean-jacques, 17 years ago

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).

comment:3 by Frank Mehnert, 17 years ago

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.

comment:4 by jean-jacques, 17 years ago

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.

comment:5 by Frank Mehnert, 17 years ago

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

comment:6 by jean-jacques, 17 years ago

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 ?

comment:7 by Frank Mehnert, 17 years ago

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.

comment:8 by jean-jacques, 17 years ago

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.

comment:9 by Frank Mehnert, 17 years ago

Resolution: invalid
Status: newclosed

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

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use