Hi! > May I ask why there needs to be a distinction between "parent" and > "child" embedded into the checkpoint implementation, going as far as > checking 'p' or 'c' read from FIFO? Why does it matter? > I guess it adds a little to "code safety", but also severely limits > the use cases for checkpointing. Why not simply have a "regular" mutex > lock, like ie. pthread mutexes?
The distinction is unfortunately mandated by the differencies between the parent (main test process) and child (forked process). The parent is expected to prepare the testing environment and also do a cleanup and therefore uses the tst_* interface, passes the cleanup function pointer to the calls etc. The parent also includes timeout logic which ensures that the parent does not hang while waiting for children to come up. The child processes does only the some test related task and does not use the tst_ interface, exit with plain exit(), etc. The letter that is send around is different in order to enforce that the right function is called, no more no less. What this avoids, for example, is calling cleanup callback from the child process that is common mistake which leads to ugly race conditions. Note also that before commit 8c1e0b3afe4f1c4da32fe7d1b5fa9738aacacab4 any usage of tst_* interface in child processes was strongly discouraged. Maybe we can rethink the API a bit now... > Going a bit further - wouldn't it be easier to simply let the test(s) > use sysv ipc, with tstlib-created objects (IPC_PRIVATE), providing > semi-safe macros for svipc(7) functions (permitting ie. EAGAIN)? > > (or even use sysv ipc for the mutex implementation, think semtimedop(2) > instead of open_wronly_timed) I've considered that. There are a few downsides to this approach. Apart from these being global system resources the reason why I've choosen fifos over these is that they can be compiled out of kernel and there are minimal systems out there run fine without them. And while I do not care much that sysvipc tests are broken on such configuration I certainly do not want to break rest of the testcases. -- Cyril Hrubis chru...@suse.cz ------------------------------------------------------------------------------ Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
