All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Campbell <Ian.Campbell@citrix.com>
To: Simon Rowe <Simon.Rowe@eu.citrix.com>
Cc: Roger Pau Monne <roger.pau@citrix.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	David Vrabel <david.vrabel@citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH] xs: set read_thread stacksize
Date: Wed, 30 May 2012 10:40:15 +0100	[thread overview]
Message-ID: <1338370815.31698.26.camel@zakaz.uk.xensource.com> (raw)
In-Reply-To: <201205300856.15605.simon.rowe@eu.citrix.com>

On Wed, 2012-05-30 at 08:56 +0100, Simon Rowe wrote:
> On Tuesday 29 May 2012 20:39:33 Ian Campbell wrote:
> 
> > ...and if it were then autoconf is the way to figure that out now,
> > unless _POSIX_THREAD_ATTR_STACKSIZE is specified somewhere (which I
> > doubt).
> 
> I was following the recommendation of the POSIX Threads: Semi-FAQ which states
> 
> 
> 5.2 How can I determine if a system supports the Stack Attribute(s)?
> 
> If the header file unistd.h defines the symbolic constant  
> _POSIX_THREAD_ATTR_STACKSIZE to a value greater than 0, the implementation 
> should support the getting and setting of the Stack Size Attribute. If it 
> defined to a value of 200112L then the current specification is supported.
> 
> 
> If this needs to be done via autoconf let me know.

If this little trick applies to both NetBSD and uclibc too then I guess
it would be OK, otherwise I think autoconf is necessary.

> > Also if it is only pthread_attr_setstacksize which is optional, rather
> > than pthread_attr_* generally, then the #if could be pulled into just
> > surround that call, presuming there is no harm in a "NULL" attr.
> 
> I don't quite get you, do you mean only protect the actual 
> pthread_attr_setstacksize() call with #ifdef and therefore always call 
> pthread_attr_init()?

Yes, that'll reduce the ifdeffery and inparticular removes the double
	if (pthread_create(&h->read_thr, NULL, read_thread, h) != 0) {
in either half, which is bit tricky to follow and is going to be prone
to drift across the two sides.

  reply	other threads:[~2012-05-30  9:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-29 15:56 [PATCH] xs: set read_thread stacksize Simon Rowe
2012-05-29 16:39 ` David Vrabel
2012-05-29 19:39   ` Ian Campbell
2012-05-30  7:56     ` Simon Rowe
2012-05-30  9:40       ` Ian Campbell [this message]
2012-05-30 12:10         ` Simon Rowe
2012-05-31  7:32           ` Ian Campbell
2012-06-21  9:09             ` Roger Pau Monne
2012-06-21  9:18               ` Ian Campbell
2012-06-21  9:39                 ` Roger Pau Monne
2012-06-21 10:18                   ` Ian Campbell
2012-06-21 10:27                     ` Roger Pau Monne
2012-06-21 10:32                       ` Ian Campbell
2012-06-21 17:19               ` Ian Jackson

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=1338370815.31698.26.camel@zakaz.uk.xensource.com \
    --to=ian.campbell@citrix.com \
    --cc=Ian.Jackson@eu.citrix.com \
    --cc=Simon.Rowe@eu.citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=xen-devel@lists.xen.org \
    /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 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.