From: Cyril Hrubis <chrubis@suse.cz>
To: Jan Stancek <jstancek@redhat.com>
Cc: ltp-list@lists.sourceforge.net
Subject: Re: [LTP] [PATCH] doc: document tst_checkpoint_create and tst_checkpoint_init
Date: Thu, 16 Oct 2014 15:01:28 +0200 [thread overview]
Message-ID: <20141016130128.GF20676@rei.suse.de> (raw)
In-Reply-To: <b8054b8185431bf461ab892b87fd647c03b323b8.1413463764.git.jstancek@redhat.com>
Hi!
> @@ -642,6 +642,22 @@ the same working directory (they use FIFO for synchronization). The checkpoint
> interface provides two pairs of signal and wait functions. One pair to be used
> to signal child from parent and second to signal parent from child.
>
> +Checkpoint is represented by 'struct tst_checkpoint', which has to be
> +initialized before first usage and FIFO has to be created. This is
> +usually done in parent process in single step by calling
> +'tst_checkpoint_create()'.
> +
> +Child processes created via fork() are ready to use tst_checkpoint_*
> +synchronization functions, as they inherited already initialized
> +'struct tst_checkpoint'.
> +
> +Child processes started via exec*, or any other process can use already
> +created FIFO, provided they initialize 'struct tst_checkpoint' first by
> +call to 'tst_checkpoint_init()'. This function does not create any FIFO,
> +it relies on fact, that it was already created by some other process.
> +Note, that if you use multiple FIFOs in this scenario, these should be
> +initialized in same order as in process you are sychronizing against.
> +
> For the details of the interface, look into the 'include/tst_checkpoint.h' and
> 'lib/tests/tst_checkpoint_*'.
Nicely done.
We should also add:
IMPORTANT: Be wary that using single checkpoint to signal child/parent followed
immediately by wait for parent/child creates an race condtion
between opening the pipe and reading from it (the process
writing to the fifo may may be the wery same process that
reads from it and the checkpoint code will exit the test
with error). You are advised to use two checkpoints in this
case.
--
Cyril Hrubis
chrubis@suse.cz
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
next prev parent reply other threads:[~2014-10-16 13:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-16 12:50 [LTP] [PATCH] doc: document tst_checkpoint_create and tst_checkpoint_init Jan Stancek
2014-10-16 13:01 ` Cyril Hrubis [this message]
[not found] ` <270995651.10143129.1413467048364.JavaMail.zimbra@redhat.com>
2014-10-16 17:34 ` Cyril Hrubis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141016130128.GF20676@rei.suse.de \
--to=chrubis@suse.cz \
--cc=jstancek@redhat.com \
--cc=ltp-list@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox