Re: [boost] [context] new version - support for Win64

Subject: Re: [boost] [context] new version - support for Win64
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2011-01-16 05:42:31

----- Original Message ----- 
From: "Oliver Kowalke" <k-oli_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, January 16, 2011 11:25 AM
Subject: Re: [boost] [context] new version - support for Win64

> 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

I see now. Can you add the constraint on the reference section? Can we force this by the C++ type system?
 
>>>> 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

I will take a look in a near future.
 
>>>>>> * 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

I think everything that can be reported to the user clearly is worth the effort. Note that otherwise you could have a lot of users asking you why this doesn't works, and you saying: "There is a warining on the documentation.". If you can you must.

Best,
Vicente