[context] new version - support for Win64
I've uploaded boost.context-0.3.0.zip to boost vault. The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler). supported platforms: i386, x86_64, arm, mips, ppc OS: UNIX, Windows (32 bit/64 bit) More details can be found in the documentation (included in the archive).
Hi, I wanted to take a look at the documentation but I can't find it in the vault (http://www.boostpro.com/vault/). Can you give a direct link? On Thu, Dec 16, 2010 at 21:06, Oliver Kowalke <k-oli@gmx.de> wrote:
I've uploaded boost.context-0.3.0.zip to boost vault.
The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler).
supported platforms: i386, x86_64, arm, mips, ppc
OS: UNIX, Windows (32 bit/64 bit)
More details can be found in the documentation (included in the archive). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
<boost-root>/libs/context/doc/html contains the documentation (included in the archive) -------- Original-Nachricht --------
Datum: Fri, 17 Dec 2010 10:35:56 +0100 Von: Klaim <mjklaim@gmail.com> An: boost@lists.boost.org Betreff: Re: [boost] [context] new version - support for Win64
Hi, I wanted to take a look at the documentation but I can't find it in the vault (http://www.boostpro.com/vault/). Can you give a direct link?
On Thu, Dec 16, 2010 at 21:06, Oliver Kowalke <k-oli@gmx.de> wrote:
I've uploaded boost.context-0.3.0.zip to boost vault.
The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler).
supported platforms: i386, x86_64, arm, mips, ppc
OS: UNIX, Windows (32 bit/64 bit)
More details can be found in the documentation (included in the archive). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
Sorry I didn't make me clear : I can't find the archive. The search fonction don't seem to work if I type "context". Can you provide a direct link to the archive file? On Fri, Dec 17, 2010 at 11:16, Oliver Kowalke <k-oli@gmx.de> wrote:
<boost-root>/libs/context/doc/html contains the documentation (included in the archive)
-------- Original-Nachricht --------
Datum: Fri, 17 Dec 2010 10:35:56 +0100 Von: Klaim <mjklaim@gmail.com> An: boost@lists.boost.org Betreff: Re: [boost] [context] new version - support for Win64
Hi, I wanted to take a look at the documentation but I can't find it in the vault (http://www.boostpro.com/vault/). Can you give a direct link?
On Thu, Dec 16, 2010 at 21:06, Oliver Kowalke <k-oli@gmx.de> wrote:
I've uploaded boost.context-0.3.0.zip to boost vault.
The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler).
supported platforms: i386, x86_64, arm, mips, ppc
OS: UNIX, Windows (32 bit/64 bit)
More details can be found in the documentation (included in the archive). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
The archive containing the sources + docu can be found at http://www.boostpro.com/vault/Concurrent Programming. http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concurrent%20Programming -------- Original-Nachricht --------
Datum: Fri, 17 Dec 2010 12:15:45 +0100 Von: Klaim <mjklaim@gmail.com> An: boost@lists.boost.org Betreff: Re: [boost] [context] new version - support for Win64
Sorry I didn't make me clear : I can't find the archive. The search fonction don't seem to work if I type "context". Can you provide a direct link to the archive file?
On Fri, Dec 17, 2010 at 11:16, Oliver Kowalke <k-oli@gmx.de> wrote:
<boost-root>/libs/context/doc/html contains the documentation (included in the archive)
-------- Original-Nachricht --------
Datum: Fri, 17 Dec 2010 10:35:56 +0100 Von: Klaim <mjklaim@gmail.com> An: boost@lists.boost.org Betreff: Re: [boost] [context] new version - support for Win64
Hi, I wanted to take a look at the documentation but I can't find it in the vault (http://www.boostpro.com/vault/). Can you give a direct link?
On Thu, Dec 16, 2010 at 21:06, Oliver Kowalke <k-oli@gmx.de> wrote:
I've uploaded boost.context-0.3.0.zip to boost vault.
The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler).
supported platforms: i386, x86_64, arm, mips, ppc
OS: UNIX, Windows (32 bit/64 bit)
More details can be found in the documentation (included in the archive). _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl
On 12/16/2010 12:06 PM, Oliver Kowalke wrote:
I've uploaded boost.context-0.3.0.zip to boost vault. [...]
For some, it might be more convenient if your project were in the sandbox: http://www.boost.org/community/sandbox.html Just a suggestion, - Jeff
The sandbox runs subversion (AFAIK) - I prefere git. Maybe the sandbpox will be migrate to git? -------- Original-Nachricht --------
Datum: Fri, 17 Dec 2010 04:10:14 -0800 Von: "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> An: boost@lists.boost.org Betreff: Re: [boost] [context] new version - support for Win64
On 12/16/2010 12:06 PM, Oliver Kowalke wrote:
I've uploaded boost.context-0.3.0.zip to boost vault. [...]
For some, it might be more convenient if your project were in the sandbox:
http://www.boost.org/community/sandbox.html
Just a suggestion,
- Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome
Maybe you can adapt to the conventions of the real world, or use git-svn? On Fri, Dec 17, 2010 at 02:12:58PM +0100, Oliver Kowalke wrote:
The sandbox runs subversion (AFAIK) - I prefere git. Maybe the sandbpox will be migrate to git?
-------- Original-Nachricht --------
Datum: Fri, 17 Dec 2010 04:10:14 -0800 Von: "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> An: boost@lists.boost.org Betreff: Re: [boost] [context] new version - support for Win64
On 12/16/2010 12:06 PM, Oliver Kowalke wrote:
I've uploaded boost.context-0.3.0.zip to boost vault. [...]
For some, it might be more convenient if your project were in the sandbox:
http://www.boost.org/community/sandbox.html
Just a suggestion,
- Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost -- Lars Viklund | zao@acc.umu.se
On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund <zao@acc.umu.se> wrote:
Maybe you can adapt to the conventions of the real world, or use git-svn?
Which real world are you talking about, the one that I live in where nobody uses SVN anymore and instead use Git for large open source development projects? :) Really, what's with all the Git hate? :D -- Dean Michael Berris about.me/deanberris
On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund <zao@acc.umu.se> wrote:
Maybe you can adapt to the conventions of the real world, or use git-svn?
Which real world are you talking about, the one that I live in where nobody uses SVN anymore and instead use Git for large open source development projects? :)
Probably the "large commercial software company" world where the source control is so bad that branches get merged once every two weeks at best, and all checkins are blocked for over 24 hours when they do, so multiple releases get worked on in the same branch just to avoid the merging headaches. ~ Scott
I think we should stop this talk - if desired you can start a new thread with this topic. It would be better if could to get some response related to boost.context. Am 18.12.2010 09:47, schrieb Scott McMurray:
On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris <mikhailberis@gmail.com> wrote:
On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao@acc.umu.se> wrote:
Maybe you can adapt to the conventions of the real world, or use git-svn?
Which real world are you talking about, the one that I live in where nobody uses SVN anymore and instead use Git for large open source development projects? :)
Probably the "large commercial software company" world where the source control is so bad that branches get merged once every two weeks at best, and all checkins are blocked for over 24 hours when they do, so multiple releases get worked on in the same branch just to avoid the merging headaches.
~ Scott _______________________________________________ Unsubscribe& other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Thursday, December 16, 2010 9:06 PM Subject: [boost] [context] new version - support for Win64
I've uploaded boost.context-0.3.0.zip to boost vault.
The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler).
supported platforms: i386, x86_64, arm, mips, ppc
OS: UNIX, Windows (32 bit/64 bit)
More details can be found in the documentation (included in the archive).
I have take a look to the documentation and I have some comments. * The sentence in the Overview "(threads are preemptively scheduled)" could be misleading as the code will in any case be run on a thread. * The documentation lacks a clear motivation for the end user. If the library is a too low level one, maybe you could add the more high level libraries that could be built on top of contexts. * How is this related to setjmp/longjmp? * How exceptions are propagated when calling to jump_to()? * Why do you need a ::create function? boost::context g() { return boost::context::create( f, 0, boost::context::default_stacksize); } why not just boost::context g() { return boost::context( f, 0, boost::context::default_stacksize); } * 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." * Some examples on the user space. A traffic light controller could show that it is possible to do it, but that more high level abstractions are needed. * Other examples of the use of the next context * Performances comparison between fiber and fcontext will be welcome Best, Vicente
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.
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Saturday, January 15, 2011 8:38 PM Subject: Re: [boost] [context] new version - support for Win64
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.
I understand. I was just only telling that the sentence was misleading and maybe you can change it.
* 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
Maybe it is worh to add something in the documentation explaining the advantages.
* 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? So if exceptions can not be propagated between contexts, how the user does with exceptions?
* 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?
* 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?
* 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.
No I mean comparaison between yous specific implementation with assembler and the use of Windows Fibers to implement Boost.Context. That is the same kind of comparison you did for UNIX. Sorry if I was not enough clear. Vicente
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'.
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
* 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.
* 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
* 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.
No I mean comparaison between yous specific implementation with assembler and the use of Windows Fibers to implement Boost.Context. That is the same kind of comparison you did for UNIX.
the code for testing the performance is only provided for UNIX - it is not ported to Windows regards, Oliver
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> 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
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
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> 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
Am 16.01.2011 11:42, schrieb vicente.botet:
----- Original Message ----- From: "Oliver Kowalke"<k-oli@gmx.de> To:<boost@lists.boost.org> 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?
no - you can't prevent that a user throws an exception.
> * 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.
I don't believe you will get an information how the compiler has implemented the exception model.
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Thursday, December 16, 2010 9:06 PM Subject: [boost] [context] new version - support for Win64
I've uploaded boost.context-0.3.0.zip to boost vault.
The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler).
I have taken a look at the implementation and I would preffer an implementation of Boost.Context much more in the spirit of a simple C++ wrapper for a low level service. IMO the cost of using Boost.Context, repect to the direct use of for example ucontext/fcontext, should be reduced to the minimum as it is a low level library. * Pimpl: The use of Pimpl idiom for a low level sevice seems to me overdesigned. * Movable: Why do we need to make context movable? Couldn't unique_ptr<context> be used to move contexts. * Stack and protection: I think that where the stack memory is located and whether it is protected or not are concerns that are independent from the context library. I would add to the context creation two parameter: the pointer to the stack and the stack size, and let the user the management of whether this memory is protected or not. The following code should IMO be on the user side std::size_t pages( helper::calc_pages( stacksize, helper::pagesize) ); if ( with_stack_protection == prot) pages += 1; // add guard page ctx.uc_stack.ss_size = pages * helper::pagesize; int fd( ::open("/dev/zero", O_RDONLY) ); if ( -1 == fd) throw std::bad_alloc(); ctx.uc_stack.ss_sp = static_cast< char * >( ::mmap( 0, ctx.uc_stack.ss_size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0) ); ::close( fd); if ( ! ctx.uc_stack.ss_sp) throw std::bad_alloc(); if ( with_stack_protection == prot) if ( 0 != ::mprotect( ctx.uc_stack.ss_sp, helper::pagesize, PROT_NONE) ) throw std::bad_alloc(); Of course the user can define his own class that gets mmap with protection or not and unmap it on destruction Maybe the library should provide the thin layer over ucontext (i.e. the fcontext implementation detail functions). We could have in addition some kind of static_context that have the stack size as template parameter and contains itself the stack memory area. Best, Vicente
Am 17.01.2011 13:36, schrieb vicente.botet:
* Pimpl: The use of Pimpl idiom for a low level sevice seems to me overdesigned.
I think it is not. With pimpl I can hide the implementation details inside the cpp-files. Otherwise I would have to mess up with compiler, architecture etc. in the header. I could not decide in the code if 'bjam toolset= architecture= instruction-set= address-model=' or 'bjam toolset=' was used (distinction between OS stack switching or via fcontext_t). With the current solution thios is done via property matching inside the Jamfile. The pimpl is also used for an efficient move-implementation.
* Movable: Why do we need to make context movable? Couldn't unique_ptr<context> be used to move contexts.
Why is boost::thread implemented with move-semantics?
* Stack and protection: I think that where the stack memory is located and whether it is protected or not are concerns that are independent from the context library. I would add to the context creation two parameter: the pointer to the stack and the stack size, and let the user the management of whether this memory is protected or not. The following code should IMO be on the user side
Some requirements must be fulfilled by the stack (alignment, hidden range for arguments) which the use may not take care of.
Maybe the library should provide the thin layer over ucontext (i.e. the fcontext implementation detail functions).
It was intented that the lib hides the concret implemntaion (ucontext_t, fcontext_t etc.).
We could have in addition some kind of static_context that have the stack size as template parameter and contains itself the stack memory area.
If the stacksize is passed as an template arg the boost::context<> would evaluate to different type for each stacksize (boost::context< 1 > is another type than boost::context< 2 >). I don't see the benefit. so long, Oliver
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Monday, January 17, 2011 5:55 PM Subject: Re: [boost] [context] Implementation comments
Am 17.01.2011 13:36, schrieb vicente.botet:
* Pimpl: The use of Pimpl idiom for a low level service seems to me overdesigned.
I think it is not. With pimpl I can hide the implementation details inside the cpp-files. Otherwise I would have to mess up with compiler, architecture etc. in the header. I could not decide in the code if 'bjam toolset= architecture= instruction-set= address-model=' or 'bjam toolset=' was used (distinction between OS stack switching or via fcontext_t).
We should be able, isn't it? If we are not able now we need to see what is missing in Boost.Config to achieve it.
With the current solution thios is done via property matching inside the Jamfile. The pimpl is also used for an efficient move-implementation.
* Movable: Why do we need to make context movable? Couldn't unique_ptr<context> be used to move contexts.
Why is boost::thread implemented with move-semantics?
Boost.Context is much more low level than Boost.Thread.
* Stack and protection: I think that where the stack memory is located and whether it is protected or not are concerns that are independent from the context library. I would add to the context creation two parameter: the pointer to the stack and the stack size, and let the user the management of whether this memory is protected or not. The following code should IMO be on the user side
Some requirements must be fulfilled by the stack (alignment, hidden range for arguments) which the use may not take care of.
Doesn't have ucontext_t the same requirements? What do you mean by hidden range for arguments? In any case I find the use of mmap a bad choice when no protection is required.
Maybe the library should provide the thin layer over ucontext (i.e. the fcontext implementation detail functions).
It was intented that the lib hides the concret implemntaion (ucontext_t, fcontext_t etc.).
Of course. But the library can provide a basic interface that hides whether you use ucontext_t or your own assembler implementation.
We could have in addition some kind of static_context that have the stack size as template parameter and contains itself the stack memory area.
If the stacksize is passed as an template arg the boost::context<> would evaluate to different type for each stacksize (boost::context< 1 > is another type than boost::context< 2 >). I don't see the benefit.
boost::static_context<N> could inherit from boost::context. But I'm not requesting this for the moment. Best, Vicente
Am 17.01.2011 18:54, schrieb vicente.botet:
* Pimpl: The use of Pimpl idiom for a low level service seems to me overdesigned.
I think it is not. With pimpl I can hide the implementation details inside the cpp-files. Otherwise I would have to mess up with compiler, architecture etc. in the header. I could not decide in the code if 'bjam toolset= architecture= instruction-set= address-model=' or 'bjam toolset=' was used (distinction between OS stack switching or via fcontext_t).
We should be able, isn't it? If we are not able now we need to see what is missing in Boost.Config to achieve it.
how would you evaluate the properties applied to bjam in the source code? this is not possible
With the current solution thios is done via property matching inside the Jamfile. The pimpl is also used for an efficient move-implementation.
* Movable: Why do we need to make context movable? Couldn't unique_ptr<context> be used to move contexts.
Why is boost::thread implemented with move-semantics?
Boost.Context is much more low level than Boost.Thread.
why? thread and context are resources - I don't see context more low level than thread
* Stack and protection: I think that where the stack memory is located and whether it is protected or not are concerns that are independent from the context library. I would add to the context creation two parameter: the pointer to the stack and the stack size, and let the user the management of whether this memory is protected or not. The following code should IMO be on the user side
Some requirements must be fulfilled by the stack (alignment, hidden range for arguments) which the use may not take care of.
Doesn't have ucontext_t the same requirements? What do you mean by hidden range for arguments?
some ABIs require some hidden space at the begin of the stack and especially alignment
In any case I find the use of mmap a bad choice when no protection is required.
why? mmap() is a good choice if you require aligned memory even if you do not use guard pages.
Maybe the library should provide the thin layer over ucontext (i.e. the fcontext implementation detail functions).
It was intented that the lib hides the concret implemntaion (ucontext_t, fcontext_t etc.).
Of course. But the library can provide a basic interface that hides whether you use ucontext_t or your own assembler implementation.
I don't understand your note - the lib does provide an abstraction over ucontext, fcontext, fibers etc.
We could have in addition some kind of static_context that have the stack size as template parameter and contains itself the stack memory area.
If the stacksize is passed as an template arg the boost::context<> would evaluate to different type for each stacksize (boost::context< 1> is another type than boost::context< 2>). I don't see the benefit.
boost::static_context<N> could inherit from boost::context. But I'm not requesting this for the moment.
sorry - I don't see any benefit of such a construction. why would you want to have different types for a context which only differ in the stacksize?
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Monday, January 17, 2011 7:55 PM Subject: Re: [boost] [context] Implementation comments
Am 17.01.2011 18:54, schrieb vicente.botet:
* Pimpl: The use of Pimpl idiom for a low level service seems to me overdesigned.
I think it is not. With pimpl I can hide the implementation details inside the cpp-files. Otherwise I would have to mess up with compiler, architecture etc. in the header. I could not decide in the code if 'bjam toolset= architecture= instruction-set= address-model=' or 'bjam toolset=' was used (distinction between OS stack switching or via fcontext_t).
We should be able, isn't it? If we are not able now we need to see what is missing in Boost.Config to achieve it.
how would you evaluate the properties applied to bjam in the source code? this is not possible
Well, we were able to go to the Moon long time ago. We can add to the project <architecture>XXX:<define>BOOST_ARCHITECTURE_XXX I guess you have see the implementation of Boost.Coroutine. Boost.Coroutine has Context concept and a model of Context is defined depending on a cetain number of compile time factors (compiler, platform, ..). Of course all the context operations can be inlinined helping surely to improve the performances.
With the current solution thios is done via property matching inside the Jamfile. The pimpl is also used for an efficient move-implementation.
* Movable: Why do we need to make context movable? Couldn't unique_ptr<context> be used to move contexts.
Why is boost::thread implemented with move-semantics?
Boost.Context is much more low level than Boost.Thread.
why? thread and context are resources - I don't see context more low level than thread
OK. I could admmit move semantics is a good thing for any user resource. Couldn't we have a more low level context abstraction that is non movable and that could be used as a member field in higher abstracions as coroutines.
* Stack and protection: I think that where the stack memory is located and whether it is protected or not are concerns that are independent from the context library. I would add to the context creation two parameter: the pointer to the stack and the stack size, and let the user the management of whether this memory is protected or not. The following code should IMO be on the user side
Some requirements must be fulfilled by the stack (alignment, hidden range for arguments) which the use may not take care of.
Doesn't have ucontext_t the same requirements? What do you mean by hidden range for arguments?
some ABIs require some hidden space at the begin of the stack and especially alignment
Can malloc be used to get this hiden space?
In any case I find the use of mmap a bad choice when no protection is required.
why? mmap() is a good choice if you require aligned memory even if you do not use guard pages.
Can malloc be used to get aligned memory?
Maybe the library should provide the thin layer over ucontext (i.e. the fcontext implementation detail functions).
It was intented that the lib hides the concret implemntaion (ucontext_t, fcontext_t etc.).
Of course. But the library can provide a basic interface that hides whether you use ucontext_t or your own assembler implementation.
I don't understand your note - the lib does provide an abstraction over ucontext, fcontext, fibers etc.
Note that I didn't talk of fibers :) As for me fibers are a higer level abstraction. Of course Fibers can be used as a detail implementation of the Context concept, but his interface shouldn't be considered when defining the one for Context.
We could have in addition some kind of static_context that have the stack size as template parameter and contains itself the stack memory area.
If the stacksize is passed as an template arg the boost::context<> would evaluate to different type for each stacksize (boost::context< 1> is another type than boost::context< 2>). I don't see the benefit.
boost::static_context<N> could inherit from boost::context. But I'm not requesting this for the moment.
sorry - I don't see any benefit of such a construction. why would you want to have different types for a context which only differ in the stacksize?
To improve the efficience of Context construction and destruction. Forget this for now please. Best, Vicente
Some requirements must be fulfilled by the stack (alignment, hidden range for arguments) which the use may not take care of.
Doesn't have ucontext_t the same requirements? What do you mean by hidden range for arguments?
some ABIs require some hidden space at the begin of the stack and especially alignment
Can malloc be used to get this hiden space?
mallolc() does add some managment stuff into the allocated memory chunk - and this what you realy don't want on your stack.
In any case I find the use of mmap a bad choice when no protection is required.
why? mmap() is a good choice if you require aligned memory even if you do not use guard pages.
Can malloc be used to get aligned memory?
malloc() uses internally mmap(). it saves only some additional data on the allocated memory chunk.
I don't understand your note - the lib does provide an abstraction over ucontext, fcontext, fibers etc.
Note that I didn't talk of fibers :) As for me fibers are a higer level abstraction. Of course Fibers can be used as a detail implementation of the Context concept, but his interface shouldn't be considered when defining the one for Context.
I refered to ucontext_t, fcontext_t and Windows Fibers - sorry to be unspecific in this point. Some additional points to your request for separating stack allocation from context creation: Windows Fiber API (which is used as an implementation detail on Windows) doesn't allow to pass an self-allocated stack to CreateFiber(). So this would break the interface of boost::context. Regards, Oliver -- GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Wednesday, January 19, 2011 9:58 AM Subject: Re: [boost] [context] Implementation comments
Some requirements must be fulfilled by the stack (alignment, hidden range for arguments) which the use may not take care of.
Doesn't have ucontext_t the same requirements? What do you mean by hidden range for arguments?
some ABIs require some hidden space at the begin of the stack and especially alignment
Can malloc be used to get this hiden space?
mallolc() does add some managment stuff into the allocated memory chunk - and this what you realy don't want on your stack.
Why?
In any case I find the use of mmap a bad choice when no protection is required.
why? mmap() is a good choice if you require aligned memory even if you do not use guard pages.
Can malloc be used to get aligned memory?
malloc() uses internally mmap(). it saves only some additional data on the allocated memory chunk.
Yes, but not at every call :)
I don't understand your note - the lib does provide an abstraction over ucontext, fcontext, fibers etc.
Note that I didn't talk of fibers :) As for me fibers are a higer level abstraction. Of course Fibers can be used as a detail implementation of the Context concept, but his interface shouldn't be considered when defining the one for Context.
I refered to ucontext_t, fcontext_t and Windows Fibers - sorry to be unspecific in this point.
What I meant is that Boost.Context could provide a low level inteface (similar to the one ucontext_t provides) which will be implemented possibily in assembler, use ucontext_t or Windows Fibers. namespace boost { namespace contexts { struct fcontext_t {...}; int get_fcontext( fcontext_t& fc); int set_fcontext( fcontext_t const& fc); int swap_fcontext( fcontext_t & ofc, fcontext_t const& nfc); int fill_fcontext( fcontext_t & fc, std::size_t size, void* stack_ptr, fcontext_t * next); int make_fcontext( fcontext_t & fc, void (* fn)( void *), void * p); }} With this minimal inteface we can create higher abstractions with a lower overhead. Note that std::size_t size, void* stack_ptr could be replaced by an abstraction that provides both informations.
Some additional points to your request for separating stack allocation from context creation: Windows Fiber API (which is used as an implementation detail on Windows) doesn't allow to pass an self-allocated stack to CreateFiber(). So this would break the interface of boost::context.
I think the interface of boost::context must be independent of the implementation details of a specific platform if in this way the interface could allow a better implementation on most of the other platforms. Instead of reducing the interface we need to make it as open as we can. The library could provide some stack allocation mechanisms which will take care of whether the implementation is using the Windows Fiber API. A user should be able to define its own allocation stack mechanism and be as efficient as possible if s/he takes in account detail implementation information provided by Boost.Context through for example a macro, BOOST_CONTEXT_MANAGE_THE_STACK or somthing like that. Vicente
What I meant is that Boost.Context could provide a low level inteface (similar to the one ucontext_t provides) which will be implemented possibily in assembler, use ucontext_t or Windows Fibers.
namespace boost { namespace contexts { struct fcontext_t {...}; int get_fcontext( fcontext_t& fc); int set_fcontext( fcontext_t const& fc); int swap_fcontext( fcontext_t & ofc, fcontext_t const& nfc); int fill_fcontext( fcontext_t & fc, std::size_t size, void* stack_ptr, fcontext_t * next); int make_fcontext( fcontext_t & fc, void (* fn)( void *), void * p); }}
With this minimal inteface we can create higher abstractions with a lower overhead.
Sorry - I don't get it. The fcontext stuff is only another implementation to store and restore registers,CPU flags and stack pointer (does the same as ucontext and Win Fibers stuff). The functions you listed are implemented in assembler using fcontext_t as data container. I don't see how this functions should abstract ucontext_t (setcontext(ucontext_t *), getcontext(ucontext_*), swapcontext( ucontext_t*,ucontext_t*), etc.) and Windows Fibers (CreateFiber(), SwitchToFiber() )? so long, Oliver -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
Am 20.01.2011 08:23, schrieb vicente.botet:
Some additional points to your request for separating stack allocation from context creation: Windows Fiber API (which is used as an implementation detail on Windows) doesn't allow to pass an self-allocated stack to CreateFiber(). So this would break the interface of boost::context.
I think the interface of boost::context must be independent of the implementation details of a specific platform if in this way the interface could allow a better implementation on most of the other platforms. Instead of reducing the interface we need to make it as open as we can.
The library could provide some stack allocation mechanisms which will take care of whether the implementation is using the Windows Fiber API. A user should be able to define its own allocation stack mechanism and be as efficient as possible if s/he takes in account detail implementation information provided by Boost.Context through for example a macro, BOOST_CONTEXT_MANAGE_THE_STACK or somthing like that.
If the ctor of boost::context takes an allocator-like object to allocate stack (how the space will be allocated can be specialized by the user) - should the lib ignore the allocator if Windows Fibers are used internally? What recommends the boost standard? Oliver
----- Original Message ----- From: "Oliver Kowalke" <k-oli@gmx.de> To: <boost@lists.boost.org> Sent: Thursday, January 20, 2011 8:38 PM Subject: Re: [boost] [context] Implementation comments
Am 20.01.2011 08:23, schrieb vicente.botet:
The library could provide some stack allocation mechanisms which will take care of whether the implementation is using the Windows Fiber API. A user should be able to define its own allocation stack mechanism and be as efficient as possible if s/he takes in account detail implementation information provided by Boost.Context through for example a macro, BOOST_CONTEXT_MANAGE_THE_STACK or somthing like that.
If the ctor of boost::context takes an allocator-like object to allocate stack (how the space will be allocated can be specialized by the user) - should the lib ignore the allocator if Windows Fibers are used internally? What recommends the boost standard?
I like the allocator idea. It seems to me evident that in this case the allocator shouldn't be used as there is no need to allocate the stack. Vicente
participants (7)
-
Dean Michael Berris -
Jeffrey Lee Hellrung, Jr. -
Klaim -
Lars Viklund -
Oliver Kowalke -
Scott McMurray -
vicente.botet