----- Original Message ----- From: "Cyril Hrubis" <[email protected]> To: "Matus Marhefka" <[email protected]> Cc: [email protected] Sent: Wednesday, December 17, 2014 3:10:28 PM Subject: Re: [LTP] [PATCH v2] containers: added mountns/mountns05.c
>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 Agree on that, I should rewrite it to use ftok() to get a key. > >* There are no timeouts, if something fails the parent may end up > waiting forever > This shouldn't happen as whole code contains error checking. If something fails it also removes the message queue and according to the man page removing the message queue also does "awakening all waiting reader and writer processes (with an error return and errno set to EIDRM)". >* 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). > >Would that solve the problem here or are there any other obstacles? > In this case 3 pipes would have to be used anyway. The solution with only one sysv message queue seems just better at least for me plus it's just for this one specific test case. >-- >Cyril Hrubis >[email protected] ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
