Subject: Re: [boost] [context] new version - support for Win64
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-16 04:50:45
----- Original Message -----
From: "Oliver Kowalke" <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Saturday, January 15, 2011 9:53 PM
Subject: Re: [boost] [context] new version - support for Win64
> Am 15.01.2011 21:17, schrieb vicente.botet:
>>>> * How exceptions are propagated when calling to jump_to()?
>>>
>>> context::jump_to() doesn't throw. as noted in the docu the code jumped
>>> into via context::jump_to() must not throw
>>
>> I don't see it on the reference part. Could you point me where it is documented?
>
> 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"
>> 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?
>>>> * Why do you need a ::create function?
>>>
>>> to have a named ctor - default ctor creates an 'not_a_context'. This is
>>> required by the move semantics
>>
>> This don't answer my question. Why you don't provide a constructor with the same parameters ::create has?
>
> for destinct/differentiate between default ctor which creates a
> 'not-a-context' and a context to which can be jumped to created by the
> named ctor context::create(). it is a question of task. I want to
> express the difference more explicit.
I don't find this more useful. I would prefer to create a context using its constructor if this is possible.
>>>> * 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?
Best,
Vicente