Re: [boost] [context] mini-review comments

Subject: Re: [boost] [context] mini-review comments
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-01-13 17:22:15

On Fri, Jan 13, 2012 at 12:54 AM, Oliver Kowalke <oliver.kowalke_at_[hidden]>wrote:
[...]

> > > Hmm - it is an implementation detail. Should I document it in the
> > > 'Rational' section?
> > >
> >
> > Well, it seems like you need to dynamically allocate *something*, and
> > whether this is through operator new, the stack allocator (probably
> > preferable...?), or something else, I think it should be documented
>
> the pattern (using pimpl; type erasure of fn() and args) is also used by
> boost::thread and boost.threads docu does not document it because it is a
> implementation detail.
>

Hmmm...I would consider that an oversight. Any operation (like calling
operator new) which changes global state should be documented as such. With
operator new, you're (likely) changing the amount of free store space,
there's possibly the acquisition of locks (depending on implementation),
and, I don't know, maybe some other effects observable outside of the local
context. If you put the pimpl in the stack space via the stack allocator,
then that changes whatever state the stack allocator has outside of the
constructor.

Example: If I write a merge sort function that allocates extra temporary
scratch space, I would consider the documentation incomplete if it didn't
mention where that scratch space is retrieved from.

[...]

> > Just to be clear: I'm asking, what are the alignment requirements of the
> > void* returned by allocate within the stack allocator concept?
> > For those who want to create their own custom stack allocator.
>
> there are no special alignment requirements - the lib does align the
> address returned by the stack allocator by itself (done inside
> boost_fcontext_make()).
>

Okay. I only suggest to clarify what properties the result of allocate()
must satisfy in the concept documentation.

> I don't think it's a good idea to guarantee (as much as one is able to,
> > anyway) a one-size-fits-all default
> > stack size for all present and future platforms for all time and across
> > all
> > dimensions and parallel universes.
>
> default_stacksize() was only introduced for more comfort for the lib users.
> I could also remove this function - but some user might ask what stacksize
> they should use.
>

I'm simply pointing out that the documented semantics of
default_stacksize() strike me as over-specified ("256 kB", regardless of
platform), and I was (implicitly) asking, e.g., if you had considered this.
Based on your above comment, it appears I didn't make my point clear
enough...

> That aside, can you provide some rationale for the specific choice of 256
> > kB? It seems rather...arbitrary, that's all. Indeed, I would've expected
> > the default stack size to be somehow related to the platform word size
> > (sizeof( void* ), maybe?).
>
> I looked at the X11 server running on my system - and its stack size was
> between 200-400kb.
>

Hmmm...suggesting this is a reasonable size on, well, the X11 server
running on your system. Do you know, by chance, how to determine the
(default?) stack size on Windows (7, specifically)?

- Jeff