------=_Part_1164_22581713.1354282524484
Content-Type: text/plain; charset=ISO-8859-1

maybe this is what you are looking for:

boost.fiber provides a kind of 'cheap' user-land threads. It provides
mutex, conditon- and event variables, barrier, channels etc. The interface
is similiar to boost.thread (== you can program like you would do it for
using boost::thread).
The library is still under construction:
https://gitorious.org/boost-dev/boost-dev/trees/fiber


Am Mittwoch, 16. Mai 2012 16:39:34 UTC+2 schrieb Greg Hickman:
>
> I'm curious whether there has been any interest or discussion within the
> committee about providing support for concurrency via user-mode threads
> that start out small and grow in size dynamically as needed, a la Go,
> Erlrang, etc.?

--




------=_Part_1164_22581713.1354282524484
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

maybe this is what you are looking for:<br><br>boost.fiber provides a kind =
of 'cheap' user-land threads. It provides mutex, conditon- and event variab=
les, barrier, channels etc. The interface is similiar to boost.thread (=3D=
=3D you can program like you would do it for using boost::thread).<br>The l=
ibrary is still under construction: https://gitorious.org/boost-dev/boost-d=
ev/trees/fiber<br><br><br>Am Mittwoch, 16. Mai 2012 16:39:34 UTC+2 schrieb =
Greg Hickman:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">I'm curious wheth=
er there has been any interest or discussion within the committee about pro=
viding support for concurrency via user-mode threads that start out small a=
nd grow in size dynamically as needed, a la Go, Erlrang, etc.?</blockquote>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1164_22581713.1354282524484--

.

------=_Part_1_25423122.1355562992769
Content-Type: text/plain; charset=ISO-8859-1



Am Freitag, 30. November 2012 14:35:24 UTC+1 schrieb oliver....@gmail.com:
>
> boost.fiber provides a kind of 'cheap' user-land threads. It provides
> mutex, conditon- and event variables, barrier, channels etc. The interface
> is similiar to boost.thread (== you can program like you would do it for
> using boost::thread).
> The library is still under construction:
> https://gitorious.org/boost-dev/boost-dev/trees/fiber


http://github.com/olk/boost-fiber

--




------=_Part_1_25423122.1355562992769
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Freitag, 30. November 2012 14:35:24 UTC+1 schrieb oliver....@gma=
il.com:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">boost.fiber provides a =
kind of 'cheap' user-land threads. It provides mutex, conditon- and event v=
ariables, barrier, channels etc. The interface is similiar to boost.thread =
(=3D=3D you can program like you would do it for using boost::thread).<br>T=
he library is still under construction: <a href=3D"https://gitorious.org/bo=
ost-dev/boost-dev/trees/fiber" target=3D"_blank">https://gitorious.org/boos=
t-<wbr>dev/boost-dev/trees/fiber</a></blockquote><div><br>http://github.com=
/olk/boost-fiber <br></div><div style=3D"display: none;" id=3D"__af745f8f43=
-e961-4b88-8424-80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1_25423122.1355562992769--

.

------=_Part_1154_21503358.1355566563290
Content-Type: text/plain; charset=ISO-8859-1

Are you talking about cooperative multitasking, aka coroutines? That's
indeed something we need.

--




------=_Part_1154_21503358.1355566563290
Content-Type: text/html; charset=ISO-8859-1

Are you talking about cooperative multitasking, aka coroutines? That's indeed something we need.<br>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1154_21503358.1355566563290--

.

------=_Part_2316_2843658.1362156130816
Content-Type: text/plain; charset=ISO-8859-1

Yes, coroutines with their own stacks.

On Saturday, December 15, 2012 4:16:03 AM UTC-6, stackm...@hotmail.com
wrote:
>
> Are you talking about cooperative multitasking, aka coroutines? That's
> indeed something we need.
>

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2316_2843658.1362156130816
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes, coroutines with their own stacks.<br><br>On Saturday, December 15, 201=
2 4:16:03 AM UTC-6, stackm...@hotmail.com wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">Are you talking about cooperative multitasking, aka corou=
tines? That's indeed something we need.<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2316_2843658.1362156130816--

.

------=_Part_551_9139572.1362162026208
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would suggest coroutines and fibers.
While coroutines are a language-level concepts (control-flow), fibers are=
=20
more os/resource-releated (similiar to threads).
Coroutines are more likely used for loops and range iteration etc. while=20
fibers are cooperative 'userland-threads'.
boost.fiber (github.com/olk/boost-fiber) for instance provides an interface=
=20
like boost.thread and you can use it like boost.thread.

BTW: boost.coroutine will support segmented stacks (=3D=3D stack grows on=
=20
demand) with boost-1.54. Unfortunately only gcc (>=3D 4.7) supports segment=
ed=20
(split-) stacks.
Might is be possible to add support for segmented stacks in the C++=20
standard?
I think dynamical growing stacks are important in the context of=20
coroutines/fibers because you can start with the lowest stack size and you=
=20
don't wast memory. Usually you
can only estimate how much your stack might be - but it might be possible=
=20
you crash your app (access violation) because your stack was to small.

Am Freitag, 1. M=E4rz 2013 17:42:10 UTC+1 schrieb Greg Hickman:
>
> Yes, coroutines with their own stacks.
>
> On Saturday, December 15, 2012 4:16:03 AM UTC-6, stackm...@hotmail.comwro=
te:
>>
>> Are you talking about cooperative multitasking, aka coroutines? That's=
=20
>> indeed something we need.
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_551_9139572.1362162026208
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I would suggest coroutines and fibers.<br>While coroutines are a language-l=
evel concepts (control-flow), fibers are more os/resource-releated (similia=
r to threads).<br>Coroutines are more likely used for loops and range itera=
tion etc. while fibers are cooperative 'userland-threads'.<br>boost.fiber (=
github.com/olk/boost-fiber) for instance provides an interface like boost.t=
hread and you can use it like boost.thread.<br><br>BTW: boost.coroutine wil=
l support segmented stacks (=3D=3D stack grows on demand) with boost-1.54. =
Unfortunately only gcc (&gt;=3D 4.7) supports segmented (split-) stacks.<br=
>Might is be possible to add support for segmented stacks in the C++ standa=
rd?<br>I think dynamical growing stacks are important in the context of cor=
outines/fibers because you can start with the lowest stack size and you don=
't wast memory. Usually you<br>can only estimate how much your stack might =
be - but it might be possible you crash your app (access violation) because=
 your stack was to small.<br><br>Am Freitag, 1. M=E4rz 2013 17:42:10 UTC+1 =
schrieb Greg Hickman:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Yes, coro=
utines with their own stacks.<br><br>On Saturday, December 15, 2012 4:16:03=
 AM UTC-6, <a>stackm...@hotmail.com</a> wrote:<blockquote class=3D"gmail_qu=
ote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding=
-left:1ex">Are you talking about cooperative multitasking, aka coroutines? =
That's indeed something we need.<br></blockquote></blockquote><div style=3D=
"display: none;" id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_551_9139572.1362162026208--

.

--20cf300faf9153f53504d6e30643
Content-Type: text/plain; charset=ISO-8859-1

On 1 Mar 2013 18:20, <oliver.kowalke@gmail.com> wrote:
>
> I would suggest coroutines and fibers.
> While coroutines are a language-level concepts (control-flow), fibers are
more os/resource-releated (similiar to threads).
> Coroutines are more likely used for loops and range iteration etc. while
fibers are cooperative 'userland-threads'.
> boost.fiber (github.com/olk/boost-fiber) for instance provides an
interface like boost.thread and you can use it like boost.thread.
>
> BTW: boost.coroutine will support segmented stacks (== stack grows on
demand) with boost-1.54. Unfortunately only gcc (>= 4.7) supports segmented
(split-) stacks.
> Might is be possible to add support for segmented stacks in the C++
standard?

I don't think the standard really has anything to say on either allowing
our forbidding segments attacks. Is there anything which currently forbids
them, or additions which would help implement them?

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



--20cf300faf9153f53504d6e30643
Content-Type: text/html; charset=ISO-8859-1

<p dir="ltr"><br>
On 1 Mar 2013 18:20, &lt;<a href="mailto:oliver.kowalke@gmail.com">oliver.kowalke@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; I would suggest coroutines and fibers.<br>
&gt; While coroutines are a language-level concepts (control-flow), fibers are more os/resource-releated (similiar to threads).<br>
&gt; Coroutines are more likely used for loops and range iteration etc. while fibers are cooperative &#39;userland-threads&#39;.<br>
&gt; boost.fiber (<a href="http://github.com/olk/boost-fiber">github.com/olk/boost-fiber</a>) for instance provides an interface like boost.thread and you can use it like boost.thread.<br>
&gt;<br>
&gt; BTW: boost.coroutine will support segmented stacks (== stack grows on demand) with boost-1.54. Unfortunately only gcc (&gt;= 4.7) supports segmented (split-) stacks.<br>
&gt; Might is be possible to add support for segmented stacks in the C++ standard?</p>
<p dir="ltr">I don&#39;t think the standard really has anything to say on either allowing our forbidding segments attacks. Is there anything which currently forbids them, or additions which would help implement them?</p>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

--20cf300faf9153f53504d6e30643--

.

------=_Part_592_18808828.1362170722452
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 21:40:58 UTC+1 schrieb Chris Jefferson:
>
>
> On 1 Mar 2013 18:20, <oliver....@gmail.com <javascript:>> wrote:
> > BTW: boost.coroutine will support segmented stacks (=3D=3D stack grows =
on=20
> demand) with boost-1.54. Unfortunately only gcc (>=3D 4.7) supports segme=
nted=20
> (split-) stacks.
> > Might is be possible to add support for segmented stacks in the C++=20
> standard?
>
> I don't think the standard really has anything to say on either allowing=
=20
> our forbidding segments attacks. Is there anything which currently forbid=
s=20
> them, or additions which would help implement them?
>
But the compiler has to provide this functionality - at least if we follow=
=20
the design of segmented (split-) stacks of GCC some functions like=20
__splitstack_makecontext() etc. must be provided by the compiler.
Otherwise each compiler vendor will come up with its own ideas of segmented=
=20
stacks should be managed be the program.=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_592_18808828.1362170722452
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 21:40:58 UTC+1 schrieb Chris Jefferson:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"><br>
On 1 Mar 2013 18:20, &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"VfgDZN2VFAUJ">oliver....@gmail.com</a>&gt; wrote:<br>
&gt; BTW: boost.coroutine will support segmented stacks (=3D=3D stack grows=
 on demand) with boost-1.54. Unfortunately only gcc (&gt;=3D 4.7) supports =
segmented (split-) stacks.<br>
&gt; Might is be possible to add support for segmented stacks in the C++ st=
andard?</p>
<p dir=3D"ltr">I don't think the standard really has anything to say on eit=
her allowing our forbidding segments attacks. Is there anything which curre=
ntly forbids them, or additions which would help implement them?</p></block=
quote><div>But the compiler has to provide this functionality - at least if=
 we follow the design of segmented (split-) stacks of GCC some functions li=
ke __splitstack_makecontext() etc. must be provided by the compiler.<br>Oth=
erwise each compiler vendor will come up with its own ideas of segmented st=
acks should be managed be the program. <br></div><div style=3D"display: non=
e;" id=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_592_18808828.1362170722452--

.

------=_Part_48_26472570.1362170922194
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 21:40:58 UTC+1 schrieb Chris Jefferson:
>
> I don't think the standard really has anything to say on either allowing=
=20
> our forbidding segments attacks. Is there anything which currently forbid=
s=20
> them, or additions which would help implement them?
>
But the compiler has to provide this functionality - at least if we follow=
=20
the design of segmented (split-) stacks from GCC. Some functions like=20
__splitstack_makecontext() etc. must be provided by the compiler in order t=
o
manage the segemented stack (increase, release, ...).
Otherwise each compiler vendor will come up with its own ideas and=20
multi-platform/multi-compiler libraries like boost is forced to hide the=20
differences. =20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_48_26472570.1362170922194
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 21:40:58 UTC+1 schrieb Chris Jefferson:<blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">I don't think the standard really has anything to say on eit=
her allowing our forbidding segments attacks. Is there anything which curre=
ntly forbids them, or additions which would help implement them?</p></block=
quote><div>But the compiler has to provide this functionality - at least if=
 we=20
follow the design of segmented (split-) stacks from GCC. Some functions=20
like __splitstack_makecontext() etc. must be provided by the compiler in or=
der to<br>manage the segemented stack (increase, release, ...).<br>Otherwis=
e each compiler vendor will come up with its own ideas and multi-platform/m=
ulti-compiler libraries like boost is forced to hide the differences.&nbsp;=
 <br></div><div style=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-=
80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_48_26472570.1362170922194--

.

------=_Part_811_303652.1362173548622
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Are you suggesting programmers would make explicit calls to manage=20
segmented stacks?  That seems like the compiler's job.

On Friday, March 1, 2013 2:48:42 PM UTC-6, Oliver Kowalke wrote:
>
> Am Freitag, 1. M=E4rz 2013 21:40:58 UTC+1 schrieb Chris Jefferson:
>>
>> I don't think the standard really has anything to say on either allowing=
=20
>> our forbidding segments attacks. Is there anything which currently forbi=
ds=20
>> them, or additions which would help implement them?
>>
> But the compiler has to provide this functionality - at least if we follo=
w=20
> the design of segmented (split-) stacks from GCC. Some functions like=20
> __splitstack_makecontext() etc. must be provided by the compiler in order=
 to
> manage the segemented stack (increase, release, ...).
> Otherwise each compiler vendor will come up with its own ideas and=20
> multi-platform/multi-compiler libraries like boost is forced to hide the=
=20
> differences. =20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_811_303652.1362173548622
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Are you suggesting programmers would make explicit calls to manage segmente=
d stacks? &nbsp;That seems like the compiler's job.<br><br>On Friday, March=
 1, 2013 2:48:42 PM UTC-6, Oliver Kowalke wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">Am Freitag, 1. M=E4rz 2013 21:40:58 UTC+1 schrieb Chris J=
efferson:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">
<p dir=3D"ltr">I don't think the standard really has anything to say on eit=
her allowing our forbidding segments attacks. Is there anything which curre=
ntly forbids them, or additions which would help implement them?</p></block=
quote><div>But the compiler has to provide this functionality - at least if=
 we=20
follow the design of segmented (split-) stacks from GCC. Some functions=20
like __splitstack_makecontext() etc. must be provided by the compiler in or=
der to<br>manage the segemented stack (increase, release, ...).<br>Otherwis=
e each compiler vendor will come up with its own ideas and multi-platform/m=
ulti-compiler libraries like boost is forced to hide the differences.&nbsp;=
 <br></div><div></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_811_303652.1362173548622--

.

------=_Part_513_12792555.1362176846241
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 22:32:28 UTC+1 schrieb Greg Hickman:
>
> Are you suggesting programmers would make explicit calls to manage=20
> segmented stacks?  That seems like the compiler's job.
>

As I said - this is how it works for GCC - the developer has to call=20
special __splitstack_<xyz>-functions before and after doing a context=20
switch:

coroutine_context::jump()
{
    __splitstack_getcontext( stack_ctx_->segments_ctx);
   __splitstack_setcontext( other.stack_ctx_->segments_ctx);
    return context::jump_fcontext( ctx_, other.ctx_, param, preserve_fpu);
   __splitstack_setcontext( stack_ctx_->segments_ctx);
}
=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_513_12792555.1362176846241
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 22:32:28 UTC+1 schrieb Greg Hickman:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">Are you suggesting programmers would make =
explicit calls to manage segmented stacks? &nbsp;That seems like the compil=
er's job.<br></blockquote><div><br>As I said - this is how it works for GCC=
 - the developer has to call special __splitstack_&lt;xyz&gt;-functions bef=
ore and after doing a context switch:<br><br>coroutine_context::jump()<br>{=
<br>&nbsp;&nbsp;&nbsp; __splitstack_getcontext( stack_ctx_-&gt;segments_ctx=
);<br>&nbsp;&nbsp; __splitstack_setcontext( other.stack_ctx_-&gt;segments_c=
tx);<br>&nbsp;&nbsp;&nbsp; return context::jump_fcontext( ctx_, other.ctx_,=
 param, preserve_fpu);<br>&nbsp;&nbsp; __splitstack_setcontext( stack_ctx_-=
&gt;segments_ctx);<br>}<br>&nbsp;<br></div><div style=3D"display: none;" id=
=3D"__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_513_12792555.1362176846241--

.

------=_Part_454_10070040.1362177921413
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable



Am Freitag, 1. M=E4rz 2013 22:32:28 UTC+1 schrieb Greg Hickman:
>
> Are you suggesting programmers would make explicit calls to manage=20
> segmented stacks?  That seems like the compiler's job
>

As I said - this is how it works for GCC - the developer has to call=20
special __splitstack_<xyz>-functions before and after doing a context=20
switch:

    __splitstack_getcontext( stack_ctx);
   __splitstack_setcontext( other.stack_ctx_);
   jump( ctx_, other.ctx_);
   __splitstack_setcontext( stack_ctx_);

=20

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_454_10070040.1362177921413
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br>Am Freitag, 1. M=E4rz 2013 22:32:28 UTC+1 schrieb Greg Hickman:<blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;">Are you suggesting programmers wou=
ld make explicit calls to manage segmented stacks? &nbsp;That seems like th=
e compiler's job<br></blockquote><div><br>As I said - this is how it works =
for GCC - the developer has to call=20
special __splitstack_&lt;xyz&gt;-functions before and after doing a=20
context switch:<br><br>&nbsp;&nbsp;&nbsp; __splitstack_getcontext( stack_ct=
x);<br>&nbsp;&nbsp; __splitstack_setcontext( other.stack_ctx_);<br><div>&nb=
sp;&nbsp; jump( ctx_, other.ctx_);<br>&nbsp;&nbsp; __splitstack_setcontext(=
 stack_ctx_);<br><br></div>&nbsp;</div><div style=3D"display: none;" id=3D"=
__af745f8f43-e961-4b88-8424-80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_454_10070040.1362177921413--

.

------=_Part_1082_26728290.1362178031210
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I guess a standard API for manually growing/shrinking stacks and switching=
=20
contexts would be better than nothing, but wouldn't something like an=20
attribute specification (e.g., [[split_stack]]) be simpler?

On Friday, March 1, 2013 4:27:26 PM UTC-6, Oliver Kowalke wrote:
>
> Am Freitag, 1. M=E4rz 2013 22:32:28 UTC+1 schrieb Greg Hickman:
>>
>> Are you suggesting programmers would make explicit calls to manage=20
>> segmented stacks?  That seems like the compiler's job.
>>
>
> As I said - this is how it works for GCC - the developer has to call=20
> special __splitstack_<xyz>-functions before and after doing a context=20
> switch:
>
> coroutine_context::jump()
> {
>     __splitstack_getcontext( stack_ctx_->segments_ctx);
>    __splitstack_setcontext( other.stack_ctx_->segments_ctx);
>     return context::jump_fcontext( ctx_, other.ctx_, param, preserve_fpu)=
;
>    __splitstack_setcontext( stack_ctx_->segments_ctx);
> }
> =20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_1082_26728290.1362178031210
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I guess a standard API for manually growing/shrinking stacks and switching =
contexts would be better than nothing, but wouldn't something like an attri=
bute specification (e.g., [[split_stack]]) be simpler?<br><br>On Friday, Ma=
rch 1, 2013 4:27:26 PM UTC-6, Oliver Kowalke wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">Am Freitag, 1. M=E4rz 2013 22:32:28 UTC+1 schrieb Greg=
 Hickman:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.=
8ex;border-left:1px #ccc solid;padding-left:1ex">Are you suggesting program=
mers would make explicit calls to manage segmented stacks? &nbsp;That seems=
 like the compiler's job.<br></blockquote><div><br>As I said - this is how =
it works for GCC - the developer has to call special __splitstack_&lt;xyz&g=
t;-functions before and after doing a context switch:<br><br>coroutine_cont=
ext::jump()<br>{<br>&nbsp;&nbsp;&nbsp; __splitstack_getcontext( stack_ctx_-=
&gt;segments_ctx);<br>&nbsp;&nbsp; __splitstack_setcontext( other.stack_ctx=
_-&gt;segments_<wbr>ctx);<br>&nbsp;&nbsp;&nbsp; return context::jump_fconte=
xt( ctx_, other.ctx_, param, preserve_fpu);<br>&nbsp;&nbsp; __splitstack_se=
tcontext( stack_ctx_-&gt;segments_ctx);<br>}<br>&nbsp;<br></div><div></div>=
</blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1082_26728290.1362178031210--

.

------=_Part_1015_20020295.1362178289159
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Er, perhaps I should have said...Wouldn't something like an attribute=20
specification (e.g., [[split_stack]]) plus some kind of API for yielding=20
the current coroutine/user-mode thread back to the runtime be simpler?

On Friday, March 1, 2013 4:47:11 PM UTC-6, Greg Hickman wrote:
>
> I guess a standard API for manually growing/shrinking stacks and switchin=
g=20
> contexts would be better than nothing, but wouldn't something like an=20
> attribute specification (e.g., [[split_stack]]) be simpler?
>
> On Friday, March 1, 2013 4:27:26 PM UTC-6, Oliver Kowalke wrote:
>>
>> Am Freitag, 1. M=E4rz 2013 22:32:28 UTC+1 schrieb Greg Hickman:
>>>
>>> Are you suggesting programmers would make explicit calls to manage=20
>>> segmented stacks?  That seems like the compiler's job.
>>>
>>
>> As I said - this is how it works for GCC - the developer has to call=20
>> special __splitstack_<xyz>-functions before and after doing a context=20
>> switch:
>>
>> coroutine_context::jump()
>> {
>>     __splitstack_getcontext( stack_ctx_->segments_ctx);
>>    __splitstack_setcontext( other.stack_ctx_->segments_ctx);
>>     return context::jump_fcontext( ctx_, other.ctx_, param, preserve_fpu=
);
>>    __splitstack_setcontext( stack_ctx_->segments_ctx);
>> }
>> =20
>>
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_1015_20020295.1362178289159
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Er, perhaps I should have said...Wouldn't something like an attribute speci=
fication (e.g., [[split_stack]]) plus some kind of API for yielding the cur=
rent coroutine/user-mode thread back to the runtime be simpler?<br><br>On F=
riday, March 1, 2013 4:47:11 PM UTC-6, Greg Hickman wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;">I guess a standard API for manually growing/shr=
inking stacks and switching contexts would be better than nothing, but woul=
dn't something like an attribute specification (e.g., [[split_stack]]) be s=
impler?<br><br>On Friday, March 1, 2013 4:27:26 PM UTC-6, Oliver Kowalke wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;b=
order-left:1px #ccc solid;padding-left:1ex">Am Freitag, 1. M=E4rz 2013 22:3=
2:28 UTC+1 schrieb Greg Hickman:<blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Are=
 you suggesting programmers would make explicit calls to manage segmented s=
tacks? &nbsp;That seems like the compiler's job.<br></blockquote><div><br>A=
s I said - this is how it works for GCC - the developer has to call special=
 __splitstack_&lt;xyz&gt;-functions before and after doing a context switch=
:<br><br>coroutine_context::jump()<br>{<br>&nbsp;&nbsp;&nbsp; __splitstack_=
getcontext( stack_ctx_-&gt;segments_ctx);<br>&nbsp;&nbsp; __splitstack_setc=
ontext( other.stack_ctx_-&gt;segments_<wbr>ctx);<br>&nbsp;&nbsp;&nbsp; retu=
rn context::jump_fcontext( ctx_, other.ctx_, param, preserve_fpu);<br>&nbsp=
;&nbsp; __splitstack_setcontext( stack_ctx_-&gt;segments_ctx);<br>}<br>&nbs=
p;<br></div><div></div></blockquote></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1015_20020295.1362178289159--

.

------=_Part_493_23552205.1362178945760
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 23:51:29 UTC+1 schrieb Greg Hickman:
>
> Er, perhaps I should have said...Wouldn't something like an attribute=20
> specification (e.g., [[split_stack]]) plus some kind of API for yielding=
=20
> the current coroutine/user-mode thread back to the runtime be simpler?
>>
>>
maybe - what I don't want is that each compiler vendor comes up with its=20
own API.
the developer should still be able to use its own context-swapping code=20
together with the [[split_stack]]-what ever.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_493_23552205.1362178945760
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Freitag, 1. M=E4rz 2013 23:51:29 UTC+1 schrieb Greg Hickman:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">Er, perhaps I should have said...Wouldn't =
something like an attribute specification (e.g., [[split_stack]]) plus some=
 kind of API for yielding the current coroutine/user-mode thread back to th=
e runtime be simpler?<blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><=
/blockquote><div><br>maybe - what I don't want is that each compiler vendor=
 comes up with its own API.<br>the developer should still be able to use it=
s own context-swapping code together with the [[split_stack]]-what ever.<br=
></div><div style=3D"display: none;" id=3D"__af745f8f43-e961-4b88-8424-80b6=
7790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_493_23552205.1362178945760--

.

------=_Part_1516_15672618.1362183029827
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As far as I can tell, it doesn't appear as though C++ implementers are=20
particularly interested at all.

On Friday, March 1, 2013 5:02:25 PM UTC-6, Oliver Kowalke wrote:
>
> Am Freitag, 1. M=E4rz 2013 23:51:29 UTC+1 schrieb Greg Hickman:
>>
>> Er, perhaps I should have said...Wouldn't something like an attribute=20
>> specification (e.g., [[split_stack]]) plus some kind of API for yielding=
=20
>> the current coroutine/user-mode thread back to the runtime be simpler?
>>>
>>>
> maybe - what I don't want is that each compiler vendor comes up with its=
=20
> own API.
> the developer should still be able to use its own context-swapping code=
=20
> together with the [[split_stack]]-what ever.
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_1516_15672618.1362183029827
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

As far as I can tell, it doesn't appear as though C++ implementers are part=
icularly interested at all.<br><br>On Friday, March 1, 2013 5:02:25 PM UTC-=
6, Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Am Fre=
itag, 1. M=E4rz 2013 23:51:29 UTC+1 schrieb Greg Hickman:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Er, perhaps I should have said...Wouldn't something =
like an attribute specification (e.g., [[split_stack]]) plus some kind of A=
PI for yielding the current coroutine/user-mode thread back to the runtime =
be simpler?<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:=
0.8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></blockquot=
e><div><br>maybe - what I don't want is that each compiler vendor comes up =
with its own API.<br>the developer should still be able to use its own cont=
ext-swapping code together with the [[split_stack]]-what ever.<br></div><di=
v></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1516_15672618.1362183029827--

.

------=_Part_76_21616505.1362216640360
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 2. M=E4rz 2013 01:10:29 UTC+1 schrieb Greg Hickman:
>
> As far as I can tell, it doesn't appear as though C++ implementers are=20
> particularly interested at all.
>

C++ developers are not interested in userland-threads or segmented stacks?

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_76_21616505.1362216640360
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 2. M=E4rz 2013 01:10:29 UTC+1 schrieb Greg Hickman:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">As far as I can tell, it doesn't appear as=
 though C++ implementers are particularly interested at all.<br></blockquot=
e><div><br>C++ developers are not interested in userland-threads or segment=
ed stacks?<br></div><div style=3D"display: none;" id=3D"__af745f8f43-e961-4=
b88-8424-80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_76_21616505.1362216640360--

.

------=_Part_121_21807505.1362218631231
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think there are many users who would be thrilled to have them.  However,=
=20
neither compiler implementers (e.g., Microsoft, Intel, etc.) nor other=20
prominent ISO C++ committee members appear to be interested because the=20
idea has received no serious consideration within the committee itself (as=
=20
best I can tell).

On Saturday, March 2, 2013 3:30:40 AM UTC-6, Oliver Kowalke wrote:
>
> Am Samstag, 2. M=E4rz 2013 01:10:29 UTC+1 schrieb Greg Hickman:
>>
>> As far as I can tell, it doesn't appear as though C++ implementers are=
=20
>> particularly interested at all.
>>
>
> C++ developers are not interested in userland-threads or segmented stacks=
?
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_121_21807505.1362218631231
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I think there are many users who would be thrilled to have them.  Howe=
ver, neither compiler implementers (e.g., Microsoft, Intel, etc.) nor other=
 prominent ISO C++ committee members appear to be interested because the id=
ea has received no serious consideration within the committee itself (as be=
st I can tell).<br><br>On Saturday, March 2, 2013 3:30:40 AM UTC-6, Oliver =
Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Am Samstag, 2. M=
=E4rz 2013 01:10:29 UTC+1 schrieb Greg Hickman:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex">As far as I can tell, it doesn't appear as though C++ implement=
ers are particularly interested at all.<br></blockquote><div><br>C++ develo=
pers are not interested in userland-threads or segmented stacks?<br></div><=
div></div></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_121_21807505.1362218631231--

.

------=_Part_1488_13324845.1362220070408
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 2. M=E4rz 2013 11:03:51 UTC+1 schrieb Greg Hickman:
>
> I think there are many users who would be thrilled to have them.  However=
,=20
> neither compiler implementers (e.g., Microsoft, Intel, etc.) nor other=20
> prominent ISO C++ committee members appear to be interested because the=
=20
> idea has received no serious consideration within the committee itself (a=
s=20
> best I can tell).
>

OK - I think fibers should get some focus because they could help to solve=
=20
the 'many dependent task problem' (task waiting on result of their=20
sub-tasks) without blocking the thread - at least that's what I try to=20
solve with boost.fiber.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_1488_13324845.1362220070408
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Am Samstag, 2. M=E4rz 2013 11:03:51 UTC+1 schrieb Greg Hickman:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">I think there are many users who would be =
thrilled to have them. &nbsp;However, neither compiler implementers (e.g., =
Microsoft, Intel, etc.) nor other prominent ISO C++ committee members appea=
r to be interested because the idea has received no serious consideration w=
ithin the committee itself (as best I can tell).<br></blockquote><div><br>O=
K - I think fibers should get some focus because they could help to solve t=
he 'many dependent task problem' (task waiting on result of their sub-tasks=
) without blocking the thread - at least that's what I try to solve with bo=
ost.fiber.<br><br></div><div style=3D"display: none;" id=3D"__af745f8f43-e9=
61-4b88-8424-80b67790c964__"></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1488_13324845.1362220070408--

.

On 3/2/13, Greg Hickman <jghickman@gmail.com> wrote:
> On Saturday, March 2, 2013 3:30:40 AM UTC-6, Oliver Kowalke wrote:
> > Am Samstag, 2. M=E4rz 2013 01:10:29 UTC+1 schrieb Greg Hickman:
> > > As far as I can tell, it doesn't appear as though C++
> > > implementers are particularly interested at all.
> >
> > C++ developers are not interested in userland-threads or
> > segmented stacks?
>
> I think there are many users who would be thrilled to have them.
> However, neither compiler implementers (e.g., Microsoft, Intel,
> etc.) nor other prominent ISO C++ committee members appear to be
> interested because the idea has received no serious consideration
> within the committee itself (as best I can tell).

There has been no serious consideration because the committee had no
time during the development of C++11.  We explicitly decided not to
do thread pools for a lack of time, which are an obvious omission.
Now, though, C++11 is done and we are considering new things.
Put together a thoughtful proposal and I'm sure it will be considered
seriously, though probably for C++17 rather than C++14.

--=20
Lawrence Crowl

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



.

------=_Part_1654_22401975.1362491211743
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Perhaps this discussion has become the beginning of that process.  Thanks=
=20
for the reply!

On Sunday, March 3, 2013 11:05:43 PM UTC-6, Lawrence Crowl wrote:
>
> On 3/2/13, Greg Hickman <jghi...@gmail.com <javascript:>> wrote:=20
> > On Saturday, March 2, 2013 3:30:40 AM UTC-6, Oliver Kowalke wrote:=20
> > > Am Samstag, 2. M=E4rz 2013 01:10:29 UTC+1 schrieb Greg Hickman:=20
> > > > As far as I can tell, it doesn't appear as though C++=20
> > > > implementers are particularly interested at all.=20
> > >=20
> > > C++ developers are not interested in userland-threads or=20
> > > segmented stacks?=20
> >=20
> > I think there are many users who would be thrilled to have them.=20
> > However, neither compiler implementers (e.g., Microsoft, Intel,=20
> > etc.) nor other prominent ISO C++ committee members appear to be=20
> > interested because the idea has received no serious consideration=20
> > within the committee itself (as best I can tell).=20
>
> There has been no serious consideration because the committee had no=20
> time during the development of C++11.  We explicitly decided not to=20
> do thread pools for a lack of time, which are an obvious omission.=20
> Now, though, C++11 is done and we are considering new things.=20
> Put together a thoughtful proposal and I'm sure it will be considered=20
> seriously, though probably for C++17 rather than C++14.=20
>
> --=20
> Lawrence Crowl=20
>

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.



------=_Part_1654_22401975.1362491211743
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Perhaps this discussion has become the beginning of that process. &nbsp;Tha=
nks for the reply!<br><br>On Sunday, March 3, 2013 11:05:43 PM UTC-6, Lawre=
nce Crowl wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 3/2/13, Gre=
g Hickman &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"Vi_2fejmX5cJ">jghi...@gmail.com</a>&gt; wrote:
<br>&gt; On Saturday, March 2, 2013 3:30:40 AM UTC-6, Oliver Kowalke wrote:
<br>&gt; &gt; Am Samstag, 2. M=E4rz 2013 01:10:29 UTC+1 schrieb Greg Hickma=
n:
<br>&gt; &gt; &gt; As far as I can tell, it doesn't appear as though C++
<br>&gt; &gt; &gt; implementers are particularly interested at all.
<br>&gt; &gt;
<br>&gt; &gt; C++ developers are not interested in userland-threads or
<br>&gt; &gt; segmented stacks?
<br>&gt;
<br>&gt; I think there are many users who would be thrilled to have them.
<br>&gt; However, neither compiler implementers (e.g., Microsoft, Intel,
<br>&gt; etc.) nor other prominent ISO C++ committee members appear to be
<br>&gt; interested because the idea has received no serious consideration
<br>&gt; within the committee itself (as best I can tell).
<br>
<br>There has been no serious consideration because the committee had no
<br>time during the development of C++11. &nbsp;We explicitly decided not t=
o
<br>do thread pools for a lack of time, which are an obvious omission.
<br>Now, though, C++11 is done and we are considering new things.
<br>Put together a thoughtful proposal and I'm sure it will be considered
<br>seriously, though probably for C++17 rather than C++14.
<br>
<br>--=20
<br>Lawrence Crowl
<br></blockquote>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_1654_22401975.1362491211743--

.