|
Boost : |
Subject: Re: [boost] Boost.Context review result
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2011-05-15 13:07:05
Am 15.05.2011 18:28, schrieb Charlls Quarra:
> thanks Vicente for the review work
>
>
> --- Saturday 14-may-11, Vicente BOTET<vicente.botet_at_[hidden]> wrote:
>
>> 2. The stack implementation must ensure that the stack is
>> unwound before it is destroyed. A stack should only be
>> safely deallocated if either has been completely unwound or
>> if it doesn't own any resources.
>>
>> A basic stack without protection seems mandatory.
>>
boost.context will provide only the protected_stack implementation
because I won't be responsible for an unsafe stack when its size is
exceeded and the application shows a strange
behavour because off memory over-writes.
But the desing allows that the user can implmenet and use its own stack
implementation (protected or not).
> I'm assuming you mean that the built-in stack implementations that the library will provide (a mmap-protected and a unprotected implementation) will provide unwinding cleanup by default, however if i understand correctly, you will not guarantee that a user stack implementation will have to unwind too, or by any chance will the unwind happen outside of the stack implementation?
Stack unwinding does not the stac by itself - it is triggered from the
context used together with the stack.
> i'm asking because, and i'm not sure if you (or boost) will consider this as a valid use case that should be allowed, but its possible that the user will want to deliver its own stack unwinding mechanism, for example, if the context is running JIT code generated from LLVM, the code generation might take care of explicitly unwinding the stack locals. In this case, forcing a new unwind might cause undefined behaviour.
If you don't request unwinding on boost::context (constructor or mem-fun
context::unwind_stack()) you could use your own - but it must be
triggered in a different way
> As long as the unwinding is optional to the user, i think its great to provide it by default
>
yes - its optional - please take a look into the docu
> Charles J. Quarra
>
> _______________________________________________
> Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
regards,
Oliver
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk