public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 1/2] POSIX: Allow pthread_barrier_destroy() to block
Date: Fri, 13 Oct 2017 10:58:55 +0200	[thread overview]
Message-ID: <87infj77ao.fsf@our.domain.is.not.set> (raw)
In-Reply-To: <20171012133442.GB21253@rei>

Hello,

Cyril Hrubis writes:

>> -	/* Cleanup (cancel thread in case it is still blocking */
>> +	printf("Test PASSED\n");
>
> What about we fail the test in a case that we do not get either of
> success or EBUSY? I doubt that there is any harm in making this kind of
> check here with the watchdog thread in place.
>

I suppose it would be misleading if it returned EINVAL, but it would
only be an error if it returned EINTR because that is specifically
prohibited by the spec.

Thinking about it, it is all undefined behaviour, but the test is to see
if it complies with the recommended behviour. So maybe we should fail
the test if it does not return EBUSY. If someone doesn't agree with the
recommended behaviour they can ignore the test.

I don't have a strong opinion on whether the test should pass or
fail. However I would like to have some clear rules to follow for the
POSIX tests. Like "If it is undefined behaviour then anything except a
null pointer derefernce or buffer overflow is acceptable". So basically
any behaviour that isn't obviously a security/integrity concern is OK. Or
something like "If it is undefined behaviour then we check if it follows
the recommended behaviour", and make it clear in the test description
that this test may fail on a compliant implementation.

-- 
Thank you,
Richard.

  reply	other threads:[~2017-10-13  8:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-09 10:18 [LTP] [PATCH 0/2] Updates to pthread_{barrier,cond}_destroy() Richard Palethorpe
2017-10-09 10:18 ` [LTP] [PATCH 1/2] POSIX: Allow pthread_barrier_destroy() to block Richard Palethorpe
2017-10-12 13:34   ` Cyril Hrubis
2017-10-13  8:58     ` Richard Palethorpe [this message]
2017-10-13  9:37       ` Cyril Hrubis
2017-10-13 12:57         ` Richard Palethorpe
2017-10-09 10:18 ` [LTP] [PATCH 2/2] POSIX: Allow pthread_cond_destroy " Richard Palethorpe
2017-10-12 14:01   ` Cyril Hrubis
2017-10-13  9:06     ` Richard Palethorpe
2017-10-13  9:20       ` Cyril Hrubis
2017-10-12 13:14 ` [LTP] [PATCH 0/2] Updates to pthread_{barrier,cond}_destroy() 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=87infj77ao.fsf@our.domain.is.not.set \
    --to=rpalethorpe@suse.de \
    --cc=ltp@lists.linux.it \
    /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