On Fri, Jan 13, 2012 at 12:54 AM, Oliver Kowalke <oliver.kowalke@gmx.de>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