* [LTP] [PATCH] doc: document tst_checkpoint_create and tst_checkpoint_init
@ 2014-10-16 12:50 Jan Stancek
2014-10-16 13:01 ` Cyril Hrubis
0 siblings, 1 reply; 3+ messages in thread
From: Jan Stancek @ 2014-10-16 12:50 UTC (permalink / raw)
To: ltp-list
Signed-off-by: Jan Stancek <jstancek@redhat.com>
---
doc/test-writing-guidelines.txt | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/doc/test-writing-guidelines.txt b/doc/test-writing-guidelines.txt
index 8aaa8b0..67240c2 100644
--- a/doc/test-writing-guidelines.txt
+++ b/doc/test-writing-guidelines.txt
@@ -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_*'.
--
1.7.1
------------------------------------------------------------------------------
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
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [LTP] [PATCH] doc: document tst_checkpoint_create and tst_checkpoint_init
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
[not found] ` <270995651.10143129.1413467048364.JavaMail.zimbra@redhat.com>
0 siblings, 1 reply; 3+ messages in thread
From: Cyril Hrubis @ 2014-10-16 13:01 UTC (permalink / raw)
To: Jan Stancek; +Cc: ltp-list
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LTP] [PATCH] doc: document tst_checkpoint_create and tst_checkpoint_init
[not found] ` <270995651.10143129.1413467048364.JavaMail.zimbra@redhat.com>
@ 2014-10-16 17:34 ` Cyril Hrubis
0 siblings, 0 replies; 3+ messages in thread
From: Cyril Hrubis @ 2014-10-16 17:34 UTC (permalink / raw)
To: Jan Stancek; +Cc: ltp-list
Hi!
> I thought we had this issue only in parent:
>
> ---------------------------------------------------------------------------------------------------
> parent | child
> | tst_checkpoint_child_wait
> | - has to wait until parent opens pipe for write
> tst_checkpoint_signal_child (NONBLOCK write) |
> tst_checkpoint_parent_wait (NONBLOCK read) |
> - parent now races on read with child |
> ---------------------------------------------------------------------------------------------------
>
> because child is opening always in blocking mode, it will always wait until other
> side is opened as well:
> ---------------------------------------------------------------------------------------------------
> parent | child
> | tst_checkpoint_signal_parent
> | - has to wait until parent opens pipe for read
> tst_checkpoint_parent_wait (NONBLOCK read) |
> - reads from FIFO |
> | tst_checkpoint_child_wait
> | - has to wait until parent opens pipe for write
> tst_checkpoint_signal_child (NONBLOCK write) |
> - at this point first byte was already read |
> from FIFO, parent writes second byte |
> | - and only now will child succeed opening pipe
> ---------------------------------------------------------------------------------------------------
>
> Am I missing something?
You are right. The problem here is that the fifo can be opened for
NONBLOCK reading even if there are no writers and therefore there are
two readers that fight for the data in the fifo.
The second ordering should be fine as far as I can tell.
--
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2014-10-16 17:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
[not found] ` <270995651.10143129.1413467048364.JavaMail.zimbra@redhat.com>
2014-10-16 17:34 ` Cyril Hrubis
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.