Boost logo

Boost :

Subject: Re: [boost] [context] new version - support for Win64
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-01-16 05:25:07


Am 16.01.2011 10:50, schrieb vicente.botet:
>> In the docu the interface of boost::context is described (reference
>> part) - to be more correct context::jump_to() throws if the context is
>> 'not-a-context'.
>
> Where is written in the documentation that "the code jumped into via context::jump_to() must not throw"

section 'Context Management' sub-section 'launching' -> Warning

>>> So if exceptions can not be propagated between contexts, how the user does with exceptions?
>>
>> maybe prevent exceptions or catch and log - the same as for threads
>
> With the use of futures and async we can propagate exceptions now, isn't it?
> Maybe your Boost.Fiber would support this kind of propagation?

it depends - you must not wait on the future on the same thread - you
would be deadlocked

boost.tasklet comes with an adapted future which allows to wait for an
result in the same thread

>>>>> * Could you clarify your sentence "Frame-unwind-tables instead of setjmp/longjmp based exception handling must be used in order to catch exception inside called function."
>>>>
>>>> for instance gcc supports both strategies how exceptions are
>>>> modelled/propagated. calling ::longjmp() is equivalent to throw
>>>> statement. Functions written in C++ will have unwind information by default.
>>>
>>> And how this translates to the user? Do the user needs to do someting specific?
>>
>> do not invoke a compiler argument which enables sj/lj-exception model
>
> This is clear :) Sorry, I ignored this. Could the library prevents the users if this is not the case?

It depends on the used compiler and I believe it is not worth the
trouble - a warning in the docu should be enough

so long,
Oliver


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk