Subject: Re: [boost] [context] new version - support for Win64
From: Oliver Kowalke (k-oli_at_[hidden])
Date: 2011-01-15 14:38:19
Am 15.01.2011 19:02, schrieb vicente.botet:
> * The sentence in the Overview "(threads are preemptively scheduled)" could be misleading as the code will in any case be run on a thread.
threads are scheduled by the operating system - the scheduling is
pre-emptive - the code can be suspended at (almost) any time. The
sentence should express the difference to
userland-threads/fibers/lightweight-threads (etc.) where each context
decides when it get suspended(cooperative scheduling). off curse the
context is running in one thread it will be pre-emptively suspended by
the os scheduler.
> * How is this related to setjmp/longjmp?
::longjmp() is not required to preserve the stack frame - so jumping
back to a function which was exited via ::longjump() is undefined
> * 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
> * 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
> * 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.
> * Performances comparison between fiber and fcontext will be welcome
do refer to boost.fiber? boost.fiber uses boost.context internally.
fcontext is an implementation detail of boost.context.
I don't understand the need for comparing it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk