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,

Boost list run by bdawes at, gregod at, cpdaniel at, john at