On Friday 13 January 2012 08:07:03 Cyril Hrubis wrote: > > > There are two ways to fix this, either create tst_fork() that flushes > > > the buffers before forking. This may be problematic as there is a need > > > for replacing fork() with tst_fork() in several testcases. > > > > if we wanted to be lazy, it would be easy to catch. in our test.h: > > #define fork() tst_fork() > > > > then in the single file defining tst_fork(), we do: > > #undef fork > > > > or forcing it via: > > #define fork() __use_tst_fork() > > > > but we already have to track in the ltp tests where fork() is used since > > this breaks NOMMU builds (i.e. UCLINUX), so it's not like we don't > > already have this issue. > > I don't like idea of defining fork to tst_fork that's exactly the > magic that may take hours to figure out. > > Forcing it, in this case, is probably good idea.
tst_fork() would be the route i'd prefer to go, and i think since we already take pains in this area to support NOMMU, it isn't an additional burden. as for defining fork() to an error or to tst_fork(), i'm fine with either. > > > Or we could flush the output after each test message is printed with > > > tst_resm(). That is IMHO ideal solution. The only drawback is that this > > > may interfere with timings in some testcases (but testcases that > > > expects exacts timings are usually broken anyway). > > > > i agree those tests are broken if the flushing causes issues due to a > > slow down. however, slow downs in general are not a good thing, > > especially when these are only needed for apps that fork. i'd like to > > think we could do better. > > Still I'm slighlty for this one. In general case, flushing the buffer > often is bad, but considering relatively rare usage of tst_resm() the > slowdowns woudn't be most likely measurable (and it's flushed after > every '\n' when you run the test in the terminal anyway). i just recall seeing some verbose tests in the past, and often times people are writing to logs. maybe in that case, there would be a bit of test time slow down, and if there's one thing i learned from doing release engineering at my last job, testing causes the longest delays :(. > Side effects of this are generally possitive too, the messages from > parent and child, or several threads wouldn't be so badly intermixed in > the output. does that happen ? POSIX guarantees printf() and friends to be multithreaded safe, so no lines would be inter-mingled, and they're sharing the same FILE*, so i wouldn't see adding a fflush() making a difference. > > a third option would be to use pthread_atfork(). no tracking needed in > > random tests since we can call this in the common ltp init func. > > downside is we'd have to use -pthread in our CFLAGS. > > > > $ gcc -pthread test.c && ./a.out | cat > > foo > > The -phtread changes several definitions in glibc headers so adding it > globally for all the tests seems wrong. sure, although all we really need is -lpthread > > a fifth option would be to use libdl, override the fork() symbol with our > > own and then dlsym() to the direct fork() symbol. but like the pthread > > solution, this would require linking all apps with -ldl, and it would > > only work on ELF based systems (so it would break embedded things like > > FLAT on NOMMU). > > Not to mention, this is starting to fall into 'overcomplicated solutions' > category. I would like to keep things as simple as possible. overcomplicated ? absolutely. a lot of fun and interesting to implement ? absolutely ;). -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
_______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
