On 12/17/2014 03:10 PM, Cyril Hrubis wrote: > Hi! >> I used msg IPC because this test needs to synchronize 3 processes (parent >> and 2 children) and in this case at least 6 named pipes would be needed. >> So instead 6 named pipes I used only one message queue where each process >> has its own message type. > > There are a few things I do not like about this solution: > > * There is a static IPC key compiled in the source > - we cannot run two instances of the test at once > - it may interfere with the rest of the system > > * There are no timeouts, if something fails the parent may end up > waiting forever > > * The code could be shorter, it takes more than three lines to just > send the notification. > > I guess that one of the problems is that the child processes need to > signal each other, which is something that the checkpoint code wasn't > written for. I think that it would be better to adapth the library so > that it fits the needs that has emerged. Or write better one that fits > all needs. > > Looking at the checkpoint code, we would need a two more functions > that could be used synchronize between child processes. What about: > > tst_checkpoint_signal_sibling(const char *file, const int lineno, > struct tst_checkpoint *checkpoint); > > tst_checkopint_sibling_wait(const char *file, const int lineno, > struct tst_checkpoint *checkpoint); > > Internally we can just reuse the tst_checkpoint_child_wait() and > tst_checkpoint_signal_parent() code (move it to separate static > functions and add a parameter with the character to be send/received).
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? 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) Thanks, Jiri ------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
