From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Ian Jackson <Ian.Jackson@eu.citrix.com>, xen-devel@lists.xen.org
Subject: Re: [PATCH] xenstore: set READ_THREAD_STACKSIZE to a sane value
Date: Wed, 12 Mar 2014 11:34:43 +0100 [thread overview]
Message-ID: <53203843.4020707@citrix.com> (raw)
In-Reply-To: <1394620224.21145.23.camel@kazak.uk.xensource.com>
On 12/03/14 11:30, Ian Campbell wrote:
> On Wed, 2014-03-12 at 11:27 +0100, Roger Pau Monné wrote:
>> On 11/03/14 17:52, Ian Jackson wrote:
>>> Roger Pau Monné writes ("Re: [PATCH] xenstore: set READ_THREAD_STACKSIZE to a sane value"):
>>>> On 11/03/14 17:25, Ian Jackson wrote:
>>>>> Well, actually, a malloc works, doesn't it ?
>>>>
>>>> No, actually a malloc with PTHREAD_STACK_MIN doesn't work, this sample
>>>> example program fails in the same way:
>>>
>>> Wow. I'm sure that can't be intentional.
>>
>> According to
>> http://pubs.opengroup.org/onlinepubs/7908799/xsh/limits.h.html (or at
>> least that's how I read it), it shouldn't be assumed that
>> PTHREAD_STACK_MIN will be set to a value that allows using libc calls,
>> the standard even says it's valid to set it to 0.
>
> That's not a terribly helpful definition!
>
> I don't remember seeing that when I wrote that older version.
> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_attr_setstacksize.html doesn't feel the need to talk about such things, which is rather unhelpful of it...
>
>> So I think the proposed patch (or a variation of it), is the right
>> solution, we shouldn't rely on PTHREAD_STACK_MIN being set to a sane
>> value. IMHO the only thing we should use PTHREAD_STACK_MIN for is to
>> check that the value we are passing to pthread_attr_setstacksize is valid.
>
> Yeah, it does seem that way.
For reference, here is the original reply that I've received when asking
about PTHREAD_STACK_MIN on freebsd-current:
http://lists.freebsd.org/pipermail/freebsd-current/2014-March/048885.html
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2014-03-12 10:34 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-07 12:22 [PATCH] xenstore: set READ_THREAD_STACKSIZE to a sane value Roger Pau Monne
2014-03-10 17:12 ` Ian Jackson
2014-03-11 13:24 ` Ian Campbell
2014-03-11 13:52 ` Roger Pau Monné
2014-03-11 14:12 ` Ian Campbell
2014-03-11 15:55 ` Roger Pau Monné
2014-03-11 16:03 ` Ian Campbell
2014-03-11 16:10 ` Ian Campbell
2014-03-11 16:18 ` Roger Pau Monné
2014-03-11 16:22 ` Ian Campbell
2014-03-11 16:25 ` Ian Jackson
2014-03-11 16:32 ` Ian Campbell
2014-03-11 16:42 ` Roger Pau Monné
2014-03-11 16:52 ` Ian Jackson
2014-03-12 10:27 ` Roger Pau Monné
2014-03-12 10:30 ` Ian Campbell
2014-03-12 10:34 ` Roger Pau Monné [this message]
2014-03-18 17:16 ` Ian Campbell
2014-03-18 17:20 ` Ian Jackson
2014-03-21 12:18 ` Ian Campbell
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=53203843.4020707@citrix.com \
--to=roger.pau@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.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.