* Yannick Brosseau ([email protected]) wrote: > > >>>> > >>> I'm afraid we're falling into a bit of a trap here. The trap is called > >>> "fixing the test-case instead of fixing the code". It's quite typical > >>> > >> No that's not the case here. I'm fixing the test case, so it shows us a > >> problem that was occuring randomly before. > >> With my "fix" to the test case, the test case will fail all the time and > >> showing us the problem when we fork later. (Some application do it, so > >> UST should not fail there) > >> > > So you're saying that this causes the test case to fail all the time > > because now we leave time for things to properly initialise, while if > > we don't initialise things sometimes work? > > I think I understand what you mean but I still don't agree. What about > > making sure somehow that we are fully initialized before we hit > > main()? In the case where we are tracing from startup using usttrace > > we should in fact be fully initialised before we allow the program to > > enter main. > > > > If you don't think we should be fully initialized before entering > > main() please explain why. > > I have no real opinion on the initialization, I don't have enough > knowledge about it right now. > But I see no real needs for the consumerd to be started before we start > main. I can imagine cases where we want to get to main the fastest way > possible and leave the unnecessary things for later. > > That being said, my goal right now it to get a test suite that do useful > tests and can identify problems and the change I propose to the test are > finding problems. > > Also, if we decide that we need to be fully initialized, we will need to > write a test case that can test that.
Exactly. I think we need to test: - case where app is started slightly before consumerd - case where app is started after consumerd Thanks, Mathieu > > _______________________________________________ > ltt-dev mailing list > [email protected] > http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev > -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com _______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
