Boost logo

Boost :

Subject: Re: [boost] [context review] Review - alternative version available
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-03-23 13:09:02


> Message du 23/03/11 17:47
> De : "Oliver Kowalke"
> A : boost_at_[hidden]
> Copie à :
> Objet : Re: [boost] [context review] Review - alternative version available
>
> Am 23.03.2011 17:35, schrieb Vicente BOTET:
> >
> >
> >> Message du 23/03/11 14:51
> >> De : "Oliver Kowalke"
> >> A : boost_at_[hidden]
> >> Copie à :
> >> Objet : Re: [boost] [context review] Review - alternative version available
> >>
> >> Hello Vicente,
> >>
> >>> I would like to see a good rationale
> >>> explaining the advantages of letting Boost.Context manage them. In any case
> >>> the name asm_impl and native_impl are not adapted. I let you make some better
> >>> suggestions than the current ones.
> >> What about dropping context< stack, impl> in favour of fast_context< stack> and native_context< stack> (nastive_context<> doesn't describe it well - do you have a better idea?).
> >> The user has the opertunity to choos which context he wants to use.
> > Hi,
> >
> > I'm still looking for the use case. What could make a user that has the possibility to get a fast context switch 13x faster to prefers to use the low context provided using ucontext?
> >
>
> You suggest that context<> should use fcontext if available and native
> OS facility otherwise?! If the other people agree I'll implement it.
> Maybe I should remove the stack template argument so that context only
> supports protected_stack (for security reasons -> overwriting memory of
> the app if stacksize is too small)?

I remember that protected_stack made use of mmap. I will prefer to been able to don't depend on mmap for this purpose and been able to use static allocation.
I don't know if this is pre-optimization.

Best,
Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk