www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Windows: Throwing Exceptions from Fibers in D2.059: Access Violation

reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
I sent this to the mailing list but as it appears to be awaiting 
moderation, here might be a more appropriate place for discussion.

Throwing exceptions from fibers seems buggy on Windows in the 
latest D2 runtime. Even a small modification to the example given 
in the unit test (adding unrelated exception handling to the same 
scope) fails with a "Stack Overflow" exception then tons of 
access violations:

    enum MSG = "Test message.";
    string caughtMsg;
    (new Fiber({
        try
        {
            throw new Exception(MSG);
        }
        catch (Exception e)
        {
            caughtMsg = e.msg;
        }
    })).call();
    assert(caughtMsg == MSG);
    // Add these two lines
    try { caughtMsg = "Hello"; }
    catch (Exception e) { caughtMsg = "World"; }

It seems brittle as well. Adding a "assert(caughtMsg == 
"Hello");" to the end of the above program for instance avoids 
the access violations (but still shows the stack overflow in the 
debugger). Similarly playing with the caughtMsg assignments 
(omitting one) or adding another assert at the end of the program 
will sometimes cause the program to run without error. This is in 
debug mode with optimizations off to theoretically avoid dead 
code elimination, but clearly something is easily thrown off.

I take it that not too many people are using Fibers on windows, 
but I really need them for a project that I'm working on. 
Alternatively I've considered trying to wrap native Win32 API 
Fibers to accomplish something similar, but I'm not sure of the 
difficulty of that. Anyone done this or have recommendations of a 
similar workaround? I really do need both fibers/coroutines and 
exceptions to express what I'm trying to do in a clean and 
efficient manner. I've considered switching to Go, but I've got 
some really handy mixins in D that would become copy-pasted stuff 
in Go presumably.

I'm running a 32-bit D application on Windows 7 x64. I've tried 
on several machines with the same results, and the same issue was 
present in 2.058 as well.

Any ideas?
Apr 18 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 18, 2012, at 11:48 AM, Andrew Lauritzen wrote:


 I sent this to the mailing list but as it appears to be awaiting =


moderation, here might be a more appropriate place for discussion.

=20
 Throwing exceptions from fibers seems buggy on Windows in the latest =


D2 runtime. Even a small modification to the example given in the unit =
test (adding unrelated exception handling to the same scope) fails with =
a "Stack Overflow" exception then tons of access violations:

This is a regression from 2.058, correct?  Please file a bug report =
either way.  Nothing relevant should have changed in core.thread though.
Apr 18 2012
parent reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
 This is a regression from 2.058, correct?  Please file a bug 
 report either way.  Nothing relevant should have changed in 
 core.thread though.


Nope it happened in 2.058 as well (which is the first one I 
tested... I'm new to D :). Where's the best place to file a bug? 
In the bugs section of the forum or is there a formal tracker?
Apr 18 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 18, 2012, at 3:47 PM, Andrew Lauritzen wrote:


 This is a regression from 2.058, correct?  Please file a bug report =




either way.  Nothing relevant should have changed in core.thread though.

=20
 Nope it happened in 2.058 as well (which is the first one I tested... =


I'm new to D :). Where's the best place to file a bug? In the bugs =
section of the forum or is there a formal tracker?

http://d.puremagic.com/issues/=
Apr 18 2012
parent reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
 http://d.puremagic.com/issues/


Thanks, issue filed:
http://d.puremagic.com/issues/show_bug.cgi?id=7938
Apr 18 2012
parent reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
I'm still interested in if anyone has any suggested workarounds 
or experience using Win32 fibers in D2 as well.
Apr 18 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote:


 I'm still interested in if anyone has any suggested workarounds or =


experience using Win32 fibers in D2 as well.

The x32 Windows code should be pretty well tested.  If this is using the =
x64 code though, that's all quite new.  I'll give this a try when I find =
some time, but can't suggest a workaround offhand.  It almost sounds =
alignment-related, which could be tricky.
Apr 18 2012
next sibling parent reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
 The x32 Windows code should be pretty well tested.  If this is 
 using the x64 code though, that's all quite new.  I'll give 
 this a try when I find some time, but can't suggest a 
 workaround offhand.  It almost sounds alignment-related, which 
 could be tricky.


This is using the x86 (32-bit) code, so I'm not sure what could 
be going wrong. Is it well-tested on Windows too? Seems like 
something about the interaction between the fiber context/stack 
and SEH is not happy.
Apr 18 2012
parent reply "David Nadlinger" <see klickverbot.at> writes:
On Thursday, 19 April 2012 at 01:32:34 UTC, Andrew Lauritzen 
wrote:

 The x32 Windows code should be pretty well tested.  If this is 
 using the x64 code though, that's all quite new.  I'll give 
 this a try when I find some time, but can't suggest a 
 workaround offhand.  It almost sounds alignment-related, which 
 could be tricky.


 This is using the x86 (32-bit) code, so I'm not sure what could 
 be going wrong. Is it well-tested on Windows too? Seems like 
 something about the interaction between the fiber context/stack 
 and SEH is not happy.


Gah, not this again. *sigh*

It is semi-well tested as in that I'm relying on it for async I/O 
in Thrift, and its test suite now passes on every Windows box I 
tested.

If you can spare the time, it would be great if you cloud 
download DMD 2.057 and try if the test case also fails with it on 
your setup. The reason is that I changed the way the top of the 
SEH chain is set up for fibers in 2.058 to make it work on 
Windows Server 2008/2008 R2, and maybe I inadvertently screwed up 
the stack alignment/… (you have to reverse-engineer the gritty 
details of SEH as you are going, and you never know whether you 
really »got it right« in terms of Microsoft's internal specs).

David
Apr 19 2012
parent reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
 Gah, not this again. *sigh*

 It is semi-well tested as in that I'm relying on it for async 
 I/O in Thrift, and its test suite now passes on every Windows 
 box I tested.

 If you can spare the time, it would be great if you cloud 
 download DMD 2.057 and try if the test case also fails with it 
 on your setup. The reason is that I changed the way the top of 
 the SEH chain is set up for fibers in 2.058 to make it work on 
 Windows Server 2008/2008 R2, and maybe I inadvertently screwed 
 up the stack alignment/… (you have to reverse-engineer the 
 gritty details of SEH as you are going, and you never know 
 whether you really »got it right« in terms of Microsoft's 
 internal specs).


Yeah I feel your pain on Windows SEH stuff and lack of docs. I 
actually work with someone who used to work on Visual C++ so I'll 
see if I can get any info/links out of him on the subject that 
may be helpful :)

In the mean time, as per the issue in the discussion, the plot 
has thickened to include there being apparently side-effects to 
putting break-points/debugging the code itself, which throws a 
big wrench into my analysis of what is going wrong. Suffice it 
say, I'm not sure it's actually D's problem, although I'm still 
worried by the "Stack Overflow" message.

I'll grab 2.057 and give it a test though to see if the behavior 
is any different. Thanks!
Apr 19 2012
parent Sean Kelly <sean invisibleduck.org> writes:
On Apr 19, 2012, at 6:50 PM, "Andrew Lauritzen" <andrew.lauritzen gmail.com>=
 wrote:


 Gah, not this again. *sigh*
=20
 It is semi-well tested as in that I'm relying on it for async I/O in Thri=




ft, and its test suite now passes on every Windows box I tested.

=20
 If you can spare the time, it would be great if you cloud download DMD 2.=




057 and try if the test case also fails with it on your setup. The reason is=
 that I changed the way the top of the SEH chain is set up for fibers in 2.0=
58 to make it work on Windows Server 2008/2008 R2, and maybe I inadvertently=
 screwed up the stack alignment/=E2=80=A6 (you have to reverse-engineer the g=
ritty details of SEH as you are going, and you never know whether you really=
 =C2=BBgot it right=C2=AB in terms of Microsoft's internal specs).

=20
 Yeah I feel your pain on Windows SEH stuff and lack of docs. I actually wo=


rk with someone who used to work on Visual C++ so I'll see if I can get any i=
nfo/links out of him on the subject that may be helpful :)

=20
 In the mean time, as per the issue in the discussion, the plot has thicken=


ed to include there being apparently side-effects to putting break-points/de=
bugging the code itself, which throws a big wrench into my analysis of what i=
s going wrong. Suffice it say, I'm not sure it's actually D's problem, altho=
ugh I'm still worried by the "Stack Overflow" message.

=20
 I'll grab 2.057 and give it a test though to see if the behavior is any di=


fferent. Thanks!

Stack overflow?  Give the fiber a larger stack when you create it. The defau=
lt is really rather small.=20=
Apr 19 2012
prev sibling parent reply "Jameson Ernst" <j.patrick.ernst gmail.com> writes:
On Thursday, 19 April 2012 at 00:07:45 UTC, Sean Kelly wrote:

 On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote:


 I'm still interested in if anyone has any suggested 
 workarounds or experience using Win32 fibers in D2 as well.


 The x32 Windows code should be pretty well tested.  If this is 
 using the x64 code though, that's all quite new.  I'll give 
 this a try when I find some time, but can't suggest a 
 workaround offhand.  It almost sounds alignment-related, which 
 could be tricky.


Been following D for a while now, and fibers right in the std lib 
are a huge draw for me. I'm not an expert on them, but on the 
topic of x64 fibers, I have some exposure to them trying to 
contribute x64 windows support to bsnes, which uses its own 
home-grown fiber/coroutine system.

Out of curiosity I took a look at the D fiber context code, and 
noticed that the x64 windows version doesn't seem to save the 
XMM6-15 registers (unless I missed it), which is something I 
forgot to do also. MSDN indicates that they are nonvolatile, 
which could potentially cause problems for FP heavy code on x64 
windows.

Not sure if I should file a bug for this, as I haven't tried an 
x64 windows fiber in D yet to make sure it's actually a problem 
first.
Apr 19 2012
next sibling parent "Nick Sabalausky" <SeeWebsiteToContactMe semitwist.com> writes:
"Jameson Ernst" <j.patrick.ernst gmail.com> wrote in message 
news:qfsswbtsxlnxrsloxaco forum.dlang.org...

 Out of curiosity I took a look at the D fiber context code, and noticed 
 that the x64 windows version doesn't seem to save the XMM6-15 registers 
 (unless I missed it), which is something I forgot to do also. MSDN 
 indicates that they are nonvolatile, which could potentially cause 
 problems for FP heavy code on x64 windows.

 Not sure if I should file a bug for this, as I haven't tried an x64 
 windows fiber in D yet to make sure it's actually a problem first.


May as well file it just so it doesn't get lost. If it turns out to be 
invalid, it can just be closed as "invalid".
Apr 19 2012
prev sibling parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 4/19/2012 10:00 PM, Jameson Ernst wrote:

 On Thursday, 19 April 2012 at 00:07:45 UTC, Sean Kelly wrote:

 On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote:


 I'm still interested in if anyone has any suggested workarounds or
 experience using Win32 fibers in D2 as well.


 The x32 Windows code should be pretty well tested. If this is using
 the x64 code though, that's all quite new. I'll give this a try when I
 find some time, but can't suggest a workaround offhand. It almost
 sounds alignment-related, which could be tricky.


 Been following D for a while now, and fibers right in the std lib are a
 huge draw for me. I'm not an expert on them, but on the topic of x64
 fibers, I have some exposure to them trying to contribute x64 windows
 support to bsnes, which uses its own home-grown fiber/coroutine system.

 Out of curiosity I took a look at the D fiber context code, and noticed
 that the x64 windows version doesn't seem to save the XMM6-15 registers
 (unless I missed it), which is something I forgot to do also. MSDN
 indicates that they are nonvolatile, which could potentially cause
 problems for FP heavy code on x64 windows.

 Not sure if I should file a bug for this, as I haven't tried an x64
 windows fiber in D yet to make sure it's actually a problem first.


Fibers seem like a last resort to me.  They are fairly difficult to make 
bulletproof due to the thread local storage issues and a few other 
problems with context switches.  Win7 scheduling and management of real 
threads is a lot better than in previous versions, and in x64 mode there 
is also user mode scheduling (UMS) system and the library built on top 
of it (ConcRT), which gets you almost all of the benefits of fibers but 
you get to use 'real' threads, plus the added bonus of being able to 
switch to another thread when you stall on a page fault or block on a 
kernel object (something fiber's can't do).
Apr 19 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 19, 2012, at 9:37 PM, Sean Cavanaugh <WorksOnMyMachine gmail.com> wro=
te:


 On 4/19/2012 10:00 PM, Jameson Ernst wrote:

 On Thursday, 19 April 2012 at 00:07:45 UTC, Sean Kelly wrote:

 On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote:
=20

 I'm still interested in if anyone has any suggested workarounds or
 experience using Win32 fibers in D2 as well.


=20
 The x32 Windows code should be pretty well tested. If this is using
 the x64 code though, that's all quite new. I'll give this a try when I
 find some time, but can't suggest a workaround offhand. It almost
 sounds alignment-related, which could be tricky.


=20
 Been following D for a while now, and fibers right in the std lib are a
 huge draw for me. I'm not an expert on them, but on the topic of x64
 fibers, I have some exposure to them trying to contribute x64 windows
 support to bsnes, which uses its own home-grown fiber/coroutine system.
=20
 Out of curiosity I took a look at the D fiber context code, and noticed
 that the x64 windows version doesn't seem to save the XMM6-15 registers
 (unless I missed it), which is something I forgot to do also. MSDN
 indicates that they are nonvolatile, which could potentially cause
 problems for FP heavy code on x64 windows.
=20
 Not sure if I should file a bug for this, as I haven't tried an x64
 windows fiber in D yet to make sure it's actually a problem first.


=20
 Fibers seem like a last resort to me.  They are fairly difficult to make b=


ulletproof due to the thread local storage issues and a few other problems w=
ith context switches.  Win7 scheduling and management of real threads is a l=
ot better than in previous versions, and in x64 mode there is also user mode=
 scheduling (UMS) system and the library built on top of it (ConcRT), which g=
ets you almost all of the benefits of fibers but you get to use 'real' threa=
ds, plus the added bonus of being able to switch to another thread when you s=
tall on a page fault or block on a kernel object (something fiber's can't do=
).

I've thought about giving fibers their own TLS so D could have "real" user s=
pace threads. It would allow us to make the thread count in apps substantial=
ly higher if everything were a fiber and std.concurrency receive, for exampl=
e, performed a context switch instead of blocking.=20=
Apr 19 2012
parent reply "Kapps" <opantm2+spam gmail.com> writes:
On Friday, 20 April 2012 at 05:08:13 UTC, Sean Kelly wrote:

 I've thought about giving fibers their own TLS so D could have 
 "real" user space threads. It would allow us to make the thread 
 count in apps substantially higher if everything were a fiber 
 and std.concurrency receive, for example, performed a context 
 switch instead of blocking.


Would this cause a noticeable performance hit? One of the most 
important things is that fibers are incredibly cheap. For 
example, in my web server I'd like to implement being able to use 
a fiber for each request that has to wait on an asynchronous 
operation (aka, a database call or file read) to allow anothe 
request to be proecssed during the wait. If fibers had a 
noticeable performance hit (such as if they had to run per-thread 
static constructors to initialize things like TLS data), this 
would not work and I'd have to resort to essentially 
reimplementing fibers.
Apr 19 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 19, 2012, at 10:55 PM, Kapps wrote:


 On Friday, 20 April 2012 at 05:08:13 UTC, Sean Kelly wrote:

=20
 I've thought about giving fibers their own TLS so D could have "real" =




user space threads. It would allow us to make the thread count in apps =
substantially higher if everything were a fiber and std.concurrency =
receive, for example, performed a context switch instead of blocking.

=20
 Would this cause a noticeable performance hit? One of the most =


important things is that fibers are incredibly cheap. For example, in my =
web server I'd like to implement being able to use a fiber for each =
request that has to wait on an asynchronous operation (aka, a database =
call or file read) to allow anothe request to be proecssed during the =
wait. If fibers had a noticeable performance hit (such as if they had to =
run per-thread static constructors to initialize things like TLS data), =
this would not work and I'd have to resort to essentially reimplementing =
fibers.

There wouldn't me much of a performance hit, mostly an additional =
allocation and a bitcopy when creating a Fiber.  It's more that making =
this work on platforms with built-in TLS could be quite tricky.=
Apr 20 2012
parent reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
On Friday, 20 April 2012 at 17:49:52 UTC, Sean Kelly wrote:

 There wouldn't me much of a performance hit, mostly an 
 additional allocation and a bitcopy when creating a Fiber.  
 It's more that making this work on platforms with built-in TLS 
 could be quite tricky.


Note that this would somewhat sabotage their usefulness as 
coroutines, depending on how it was implemented. That's not to 
say the idea isn't good (but I'd frame it more like "tasks"; see 
Thread Building Blocks or similar), but fibers/coroutines as they 
stand now are useful so I'd hate to see that capability lost.
Apr 20 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 20, 2012, at 10:59 AM, Andrew Lauritzen wrote:


 On Friday, 20 April 2012 at 17:49:52 UTC, Sean Kelly wrote:

 There wouldn't me much of a performance hit, mostly an additional =




allocation and a bitcopy when creating a Fiber.  It's more that making =
this work on platforms with built-in TLS could be quite tricky.

 Note that this would somewhat sabotage their usefulness as coroutines, =


depending on how it was implemented. That's not to say the idea isn't =
good (but I'd frame it more like "tasks"; see Thread Building Blocks or =
similar), but fibers/coroutines as they stand now are useful so I'd hate =
to see that capability lost.

Ah, coroutines would actually want to share TLS with the executing =
thread?  That's good to know.=
Apr 20 2012
next sibling parent "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
On Friday, 20 April 2012 at 18:09:37 UTC, Sean Kelly wrote:

 Ah, coroutines would actually want to share TLS with the 
 executing thread?  That's good to know.


In my case that's definitely useful as, like I said, I'm not 
trying to express any parallelism here and don't really want to 
take on the burden of synchronizing the data structures :) I'm 
merely using coroutines as a handy way to save and restore state, 
the alternative being to do it all manually at every yield point 
(yikes!).
Apr 20 2012
prev sibling parent reply "Jameson Ernst" <j.patrick.ernst gmail.com> writes:
On Friday, 20 April 2012 at 18:09:37 UTC, Sean Kelly wrote:

 On Apr 20, 2012, at 10:59 AM, Andrew Lauritzen wrote:


 On Friday, 20 April 2012 at 17:49:52 UTC, Sean Kelly wrote:

 There wouldn't me much of a performance hit, mostly an 
 additional allocation and a bitcopy when creating a Fiber.  
 It's more that making this work on platforms with built-in 
 TLS could be quite tricky.


 Note that this would somewhat sabotage their usefulness as 
 coroutines, depending on how it was implemented. That's not to 
 say the idea isn't good (but I'd frame it more like "tasks"; 
 see Thread Building Blocks or similar), but fibers/coroutines 
 as they stand now are useful so I'd hate to see that 
 capability lost.


 Ah, coroutines would actually want to share TLS with the 
 executing thread?  That's good to know.


Yeah, I think there's a subtlety at play here, but it's an 
important one. In most languages and environments, a thread of 
execution and a call stack are conflated into a single entity. I 
think what Andrew and I are driving at is that we'd like them to 
be orthogonal concepts.

A "thread" is merely a lane of execution, and that lane can play 
host to any call-stack "fiber" context we'd like it to. For this 
reason, it's important that fibers not be bound to the thread 
that initially created them. Mono implemented a continuation 
system, but the stack context is tied to the thread that spawned 
it, which is frustrating and prevents efficient task pooling.
Apr 20 2012
parent Sean Kelly <sean invisibleduck.org> writes:
On Apr 20, 2012, at 1:42 PM, Jameson Ernst wrote:


 On Friday, 20 April 2012 at 18:09:37 UTC, Sean Kelly wrote:

 On Apr 20, 2012, at 10:59 AM, Andrew Lauritzen wrote:
=20

 On Friday, 20 April 2012 at 17:49:52 UTC, Sean Kelly wrote:

 There wouldn't me much of a performance hit, mostly an additional =








allocation and a bitcopy when creating a Fiber.  It's more that making =
this work on platforms with built-in TLS could be quite tricky.

 Note that this would somewhat sabotage their usefulness as =






coroutines, depending on how it was implemented. That's not to say the =
idea isn't good (but I'd frame it more like "tasks"; see Thread Building =
Blocks or similar), but fibers/coroutines as they stand now are useful =
so I'd hate to see that capability lost.

=20
 Ah, coroutines would actually want to share TLS with the executing =




thread?  That's good to know.

=20
 Yeah, I think there's a subtlety at play here, but it's an important =


one. In most languages and environments, a thread of execution and a =
call stack are conflated into a single entity. I think what Andrew and I =
are driving at is that we'd like them to be orthogonal concepts.

=20
 A "thread" is merely a lane of execution, and that lane can play host =


to any call-stack "fiber" context we'd like it to. For this reason, it's =
important that fibers not be bound to the thread that initially created =
them. Mono implemented a continuation system, but the stack context is =
tied to the thread that spawned it, which is frustrating and prevents =
efficient task pooling.

The weird thing in D is that static data is thread-local by default, so =
moving a fiber between threads would mean the value of statics would =
change between calls.  I had thought that by giving each fiber its own =
TLS space the programming model would be more predictable, but I can see =
how the current behavior may actually be desirable in some instances.  I =
wonder if there's any value in having a child of Fiber that has its own =
TLS, call it CoopThread or whatever.

For the record, there's absolutely nothing preventing you from moving a =
fiber across threads in Druntime.  It's absolutely legal behavior, =
despite the potential weirdness with statics.=
Apr 20 2012
prev sibling parent reply "Jameson Ernst" <j.patrick.ernst gmail.com> writes:
On Friday, 20 April 2012 at 04:37:32 UTC, Sean Cavanaugh wrote:

 On 4/19/2012 10:00 PM, Jameson Ernst wrote:

 On Thursday, 19 April 2012 at 00:07:45 UTC, Sean Kelly wrote:

 On Apr 18, 2012, at 4:06 PM, Andrew Lauritzen wrote:


 I'm still interested in if anyone has any suggested 
 workarounds or
 experience using Win32 fibers in D2 as well.


 The x32 Windows code should be pretty well tested. If this is 
 using
 the x64 code though, that's all quite new. I'll give this a 
 try when I
 find some time, but can't suggest a workaround offhand. It 
 almost
 sounds alignment-related, which could be tricky.


 Been following D for a while now, and fibers right in the std 
 lib are a
 huge draw for me. I'm not an expert on them, but on the topic 
 of x64
 fibers, I have some exposure to them trying to contribute x64 
 windows
 support to bsnes, which uses its own home-grown 
 fiber/coroutine system.

 Out of curiosity I took a look at the D fiber context code, 
 and noticed
 that the x64 windows version doesn't seem to save the XMM6-15 
 registers
 (unless I missed it), which is something I forgot to do also. 
 MSDN
 indicates that they are nonvolatile, which could potentially 
 cause
 problems for FP heavy code on x64 windows.

 Not sure if I should file a bug for this, as I haven't tried 
 an x64
 windows fiber in D yet to make sure it's actually a problem 
 first.


 Fibers seem like a last resort to me.  They are fairly 
 difficult to make bulletproof due to the thread local storage 
 issues and a few other problems with context switches.  Win7 
 scheduling and management of real threads is a lot better than 
 in previous versions, and in x64 mode there is also user mode 
 scheduling (UMS) system and the library built on top of it 
 (ConcRT), which gets you almost all of the benefits of fibers 
 but you get to use 'real' threads, plus the added bonus of 
 being able to switch to another thread when you stall on a page 
 fault or block on a kernel object (something fiber's can't do).


To be precise, fibers in and of themselves aren't exacty what I 
want, but are the best means to getting it that I've seen so far. 
They enable efficient implementation of coroutines, which many 
languages either cannot express at all, or can only express very 
poorly by using the sledgehammer of a full-on kernel thread to 
get it. A call stack is a very useful way to group logic, and 
being forced to go outside the language and ask the OS for 
another one is a shame.

Game logic is an area where this technique REALLY shines. Case in 

method facility to implement coroutines to control entity logic. 
Hundreds or even thousands of them can be active with very little 
overhead compared to a full thread context switch. Unfortunately, 
they're hamstrung by not being a true coroutine (you can only 
yield from the top frame).


and we use it extensively at work on both the client and server 
side. D could really eat its lunch by making fibers first-class 
and portable.
Apr 19 2012
parent reply "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
 To be precise, fibers in and of themselves aren't exacty what I 
 want, but are the best means to getting it that I've seen so 
 far. They enable efficient implementation of coroutines, which 
 many languages either cannot express at all, or can only 
 express very poorly by using the sledgehammer of a full-on 
 kernel thread to get it. A call stack is a very useful way to 
 group logic, and being forced to go outside the language and 
 ask the OS for another one is a shame.

 Game logic is an area where this technique REALLY shines. Case 

 iterator method facility to implement coroutines to control 
 entity logic. Hundreds or even thousands of them can be active 
 with very little overhead compared to a full thread context 
 switch. Unfortunately, they're hamstrung by not being a true 
 coroutine (you can only yield from the top frame).


Right, exactly the above! Fibers are totally uninteresting as a 
"lighter thread" or unit of scheduling for the reasons that you 
note, but coroutines are just a better way to write a lot of 
code. This is basically the entire premise for the Go programming 
language, so it's worth taking a peek at that if you haven't 
already.

In my example, it's effectively to yield and restore 
connection-specific state for different clients. In the 
equivalent C code, it's a gigantic mess of a state machine 
specified by big switch statements and is almost impossible to 
follow the intended flow. With coroutines it's quite simple: you 
write the code in the most natural way - as if your sockets were 
blocking - and when you would otherwise block, you yield the 
fiber instead and come back to it when more socket data is 
available. Go takes this a step further by embedding the yields 
(and more) into both the standard library and the language 
itself. It's quite a powerful programming model for certain types 
of work.

When I started running into fiber issues I tried to use threads 
instead (just to avoid the issues; I have no need of the 
parallelism or other utilities that they provide in this 
application) but I ran into a bunch of problems.

First, D's insistence on message-passing, while noble and 
respectable, is not a perfect fit  for cases where I have no need 
or desire to synchronize large portions of the data structures. 
In general, this sort of coarse-grained opportunistic parallelism 
extracts very few additional useful cycles out of multicore 
hardware compared to a more targeted fine-grained approach. As 
you note, there's a reason that a lot of the scheduling is 
starting to move more to user-space "tasks".

(As an aside, it would be awesome to see a Cilk-like work 
stealing implementation in D. That's by far the easiest first 
step to really extracting parallelism our of programs and you can 
often get most of the benefit just with that. It's yet another 
elegant way to use the call-stack for expressing and exploiting 
parallelism and dependencies.)

Second, and more importantly, there didn't seem to be a clean way 
to wait on multiple things in D right now. For instance, I want 
to yield a thread/fiber until there is either a socket state 
change, *or* a thread message. This can be a minor problem with 
fibers, but less-so since the fiber itself can basically just 
take over whatever work needs to be done rather than trying to 
wake other threads. There doesn't seem to be a clean way to do 
this in D currently other than waking threads and basically 
polling multiple things, which I'm sure you can agree is not 
ideal.


 Stack overflow?  Give the fiber a larger stack when you create 
 it. The default is really rather small.


I'm fairly certain that it's not a "real" stack overflow... the 
program continues to operate normally unless the debugger is 
stepping through and it only happens when an exception is thrown. 
And it happens pretty much always when an exception is thrown, 
you just won't see it unless you have a debugger attached to see 
the output. So like I said, it is somewhat worrisome, but the 
program seems to be running properly despite it, so it may be a 
red herring.
Apr 20 2012
parent reply Sean Kelly <sean invisibleduck.org> writes:
On Apr 20, 2012, at 10:21 AM, Andrew Lauritzen wrote:


 To be precise, fibers in and of themselves aren't exacty what I want, =




but are the best means to getting it that I've seen so far. They enable =
efficient implementation of coroutines, which many languages either =
cannot express at all, or can only express very poorly by using the =
sledgehammer of a full-on kernel thread to get it. A call stack is a =
very useful way to group logic, and being forced to go outside the =
language and ask the OS for another one is a shame.

=20
 Game logic is an area where this technique REALLY shines. Case in =





facility to implement coroutines to control entity logic. Hundreds or =
even thousands of them can be active with very little overhead compared =
to a full thread context switch. Unfortunately, they're hamstrung by not =
being a true coroutine (you can only yield from the top frame).

=20


 Right, exactly the above! Fibers are totally uninteresting as a =


"lighter thread" or unit of scheduling for the reasons that you note, =
but coroutines are just a better way to write a lot of code. This is =
basically the entire premise for the Go programming language, so it's =
worth taking a peek at that if you haven't already.

Okay, here's the talk:

=
http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-=
talk-video.html

I've been digging around and just found Mikola's coroutine =
implementation on my hard drive.  It would have to be updated, but I do =
have the code.  Maybe this should be added to Druntime.



 Stack overflow?  Give the fiber a larger stack when you create it. =




The default is really rather small.

=20
 I'm fairly certain that it's not a "real" stack overflow... the =


program continues to operate normally unless the debugger is stepping =
through and it only happens when an exception is thrown. And it happens =
pretty much always when an exception is thrown, you just won't see it =
unless you have a debugger attached to see the output. So like I said, =
it is somewhat worrisome, but the program seems to be running properly =
despite it, so it may be a red herring.

It could be a "real" stack overflow.  I can't remember the details, but =
this happened once before when the default stack size was 4k.  Something =
about how exceptions are thrown right now has pretty considerable stack =
requirements on Windows--maybe the stack trace generation?  Anyway, =
that's why the default stack size for fibers is currently 8k IIRC.=
Apr 20 2012
next sibling parent "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
On Friday, 20 April 2012 at 18:08:48 UTC, Sean Kelly wrote:

 It could be a "real" stack overflow.  I can't remember the 
 details, but this happened once before when the default stack 
 size was 4k.  Something about how exceptions are thrown right 
 now has pretty considerable stack requirements on 
 Windows--maybe the stack trace generation?  Anyway, that's why 
 the default stack size for fibers is currently 8k IIRC.


Interesting, ok I'll play with the stack size a bit and see what 
happens :)
Apr 20 2012
prev sibling next sibling parent "Andrew Lauritzen" <andrew.lauritzen gmail.com> writes:
On Friday, 20 April 2012 at 18:08:48 UTC, Sean Kelly wrote:

 Okay, here's the talk:

 http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html


Finally got a chance to read through the slides here - great 
stuff! This describes precisely what we're talking about and even 
gives examples of how the ugly state machine code works. It even 
calls out both games and network servers as examples of where the 
pattern is extremely useful :)
Apr 22 2012
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-20 20:08, Sean Kelly wrote:


 http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html

 I've been digging around and just found Mikola's coroutine implementation on
my hard drive.  It would have to be updated, but I do have the code.  Maybe
this should be added to Druntime.


I thought that this is what's used in druntime and Tango already?

-- 
/Jacob Carlborg
May 21 2012
next sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
On May 21, 2012, at 11:05 AM, Jacob Carlborg wrote:


 On 2012-04-20 20:08, Sean Kelly wrote:
=20

 =




http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-=
talk-video.html

=20
 I've been digging around and just found Mikola's coroutine =




implementation on my hard drive.  It would have to be updated, but I do =
have the code.  Maybe this should be added to Druntime.

=20
 I thought that this is what's used in druntime and Tango already?


Druntime Fiber is equivalent to Mikola's StackThreads, but there's no =
Coroutine class in Druntime.=
May 21 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-05-21 20:15, Sean Kelly wrote:


 Druntime Fiber is equivalent to Mikola's StackThreads, but there's no
Coroutine class in Druntime.


Aha, I see. So that's the difference ?

-- 
/Jacob Carlborg
May 22 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-05-22 09:23, Jacob Carlborg wrote:

 On 2012-05-21 20:15, Sean Kelly wrote:


 Druntime Fiber is equivalent to Mikola's StackThreads, but there's no
 Coroutine class in Druntime.


 Aha, I see. So that's the difference ?


Found the answer in an other part of the thread.

-- 
/Jacob Carlborg
May 22 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
On 21 May 2012 21:15, Sean Kelly <sean invisibleduck.org> wrote:


 On May 21, 2012, at 11:05 AM, Jacob Carlborg wrote:


 On 2012-04-20 20:08, Sean Kelly wrote:





 http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html

 I've been digging around and just found Mikola's coroutine




 implementation on my hard drive.  It would have to be updated, but I do
 have the code.  Maybe this should be added to Druntime.

 I thought that this is what's used in druntime and Tango already?


 Druntime Fiber is equivalent to Mikola's StackThreads, but there's no
 Coroutine class in Druntime.



What's the distinction between a fiber and a coroutine? I thought they were
basically synonymous.



 May 21 2012



prev sibling  parent  Sean Kelly <sean invisibleduck.org>  writes:


On May 21, 2012, at 2:55 PM, Manu wrote:


 On 21 May 2012 21:15, Sean Kelly <sean invisibleduck.org> wrote:
 On May 21, 2012, at 11:05 AM, Jacob Carlborg wrote:
=20

 On 2012-04-20 20:08, Sean Kelly wrote:


 =






http://petermodzelewski.blogspot.com/2008/10/tango-conference-2008-fibers-=
talk-video.html

 I've been digging around and just found Mikola's coroutine =






implementation on my hard drive.  It would have to be updated, but I do =
have the code.  Maybe this should be added to Druntime.

 I thought that this is what's used in druntime and Tango already?


=20
 Druntime Fiber is equivalent to Mikola's StackThreads, but there's no =


Coroutine class in Druntime.

=20
 What's the distinction between a fiber and a coroutine? I thought they =


were basically synonymous.

Coroutine is a tad higher-level, but they're functionally identical.



 May 21 2012



prev sibling  parent reply Manu <turkeyman gmail.com>  writes:


On 18 April 2012 21:48, Andrew Lauritzen <andrew.lauritzen gmail.com> wrote:


 I sent this to the mailing list but as it appears to be awaiting
 moderation, here might be a more appropriate place for discussion.

 Throwing exceptions from fibers seems buggy on Windows in the latest D2
 runtime. Even a small modification to the example given in the unit test
 (adding unrelated exception handling to the same scope) fails with a "Stack
 Overflow" exception then tons of access violations:

   enum MSG = "Test message.";
   string caughtMsg;
   (new Fiber({
       try
       {
           throw new Exception(MSG);
       }
       catch (Exception e)
       {
           caughtMsg = e.msg;
       }
   })).call();
   assert(caughtMsg == MSG);
   // Add these two lines
   try { caughtMsg = "Hello"; }
   catch (Exception e) { caughtMsg = "World"; }

 It seems brittle as well. Adding a "assert(caughtMsg == "Hello");" to the
 end of the above program for instance avoids the access violations (but
 still shows the stack overflow in the debugger). Similarly playing with the
 caughtMsg assignments (omitting one) or adding another assert at the end of
 the program will sometimes cause the program to run without error. This is
 in debug mode with optimizations off to theoretically avoid dead code
 elimination, but clearly something is easily thrown off.

 I take it that not too many people are using Fibers on windows, but I
 really need them for a project that I'm working on. Alternatively I've
 considered trying to wrap native Win32 API Fibers to accomplish something
 similar, but I'm not sure of the difficulty of that. Anyone done this or
 have recommendations of a similar workaround? I really do need both
 fibers/coroutines and exceptions to express what I'm trying to do in a
 clean and efficient manner. I've considered switching to Go, but I've got
 some really handy mixins in D that would become copy-pasted stuff in Go
 presumably.

 I'm running a 32-bit D application on Windows 7 x64. I've tried on several
 machines with the same results, and the same issue was present in 2.058 as
 well.

 Any ideas?


How far did you get using Fibers on Windows in the end?
I'm using GDC for x64 Windows, and it crashes in call(), but before it
enters the fibre function. I think it's just broken... :/
Anyone else had problems?



 May 21 2012



  parent reply "David Nadlinger" <see klickverbot.at>  writes:


On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:

 How far did you get using Fibers on Windows in the end?
 I'm using GDC for x64 Windows, and it crashes in call(), but 
 before it
 enters the fibre function. I think it's just broken... :/
 Anyone else had problems?


Fiber support should be reasonably stable on pretty much all 
flavors of Windows when using DMD (i.e. compiling for 32 bit). 
Never tested GDC…

David



 May 21 2012



 next sibling parent  Manu <turkeyman gmail.com>  writes:


On 21 May 2012 19:16, David Nadlinger <see klickverbot.at> wrote:


 On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:


 How far did you get using Fibers on Windows in the end?
 I'm using GDC for x64 Windows, and it crashes in call(), but before it
 enters the fibre function. I think it's just broken... :/
 Anyone else had problems?


 Fiber support should be reasonably stable on pretty much all flavors of
 Windows when using DMD (i.e. compiling for 32 bit). Never tested GDC=E2=


=80=A6


Hmm, well I am limited to x64, and therefore GDC... :/



 May 21 2012



prev sibling next sibling parent  Manu <turkeyman gmail.com>  writes:


On 21 May 2012 19:16, David Nadlinger <see klickverbot.at> wrote:


 On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:


 How far did you get using Fibers on Windows in the end?
 I'm using GDC for x64 Windows, and it crashes in call(), but before it
 enters the fibre function. I think it's just broken... :/
 Anyone else had problems?


 Fiber support should be reasonably stable on pretty much all flavors of
 Windows when using DMD (i.e. compiling for 32 bit). Never tested GDC=E2=


=80=A6


Mmm, I just ran some tests with DMD, seems to work. GDC, not so much :(



 May 22 2012



prev sibling next sibling parent  Sean Kelly <sean invisibleduck.org>  writes:


On May 22, 2012, at 9:17 AM, Manu wrote:


 On 21 May 2012 19:16, David Nadlinger <see klickverbot.at> wrote:
 On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:
 How far did you get using Fibers on Windows in the end?
 I'm using GDC for x64 Windows, and it crashes in call(), but before it
 enters the fibre function. I think it's just broken... :/
 Anyone else had problems?
=20
 Fiber support should be reasonably stable on pretty much all flavors =


of Windows when using DMD (i.e. compiling for 32 bit). Never tested GDC=85=


=20
 Mmm, I just ran some tests with DMD, seems to work. GDC, not so much =


:(

Is GDC broken for both 32 and 64 bit, or just 64 bit?



 May 24 2012



prev sibling next sibling parent  Manu <turkeyman gmail.com>  writes:


On 24 May 2012 21:08, Sean Kelly <sean invisibleduck.org> wrote:


 On May 22, 2012, at 9:17 AM, Manu wrote:


 On 21 May 2012 19:16, David Nadlinger <see klickverbot.at> wrote:
 On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:
 How far did you get using Fibers on Windows in the end?
 I'm using GDC for x64 Windows, and it crashes in call(), but before it
 enters the fibre function. I think it's just broken... :/
 Anyone else had problems?

 Fiber support should be reasonably stable on pretty much all flavors of


 Windows when using DMD (i.e. compiling for 32 bit). Never tested GDC=E2=


=80=A6

 Mmm, I just ran some tests with DMD, seems to work. GDC, not so much :(


 Is GDC broken for both 32 and 64 bit, or just 64 bit?


I haven't tested x32, I work with x64 exclusively.



 May 28 2012



prev sibling  parent  Sean Kelly <sean invisibleduck.org>  writes:


	charset=utf-8

On May 28, 2012, at 1:19 AM, Manu <turkeyman gmail.com> wrote:


 On 24 May 2012 21:08, Sean Kelly <sean invisibleduck.org> wrote:
 On May 22, 2012, at 9:17 AM, Manu wrote:
=20

 On 21 May 2012 19:16, David Nadlinger <see klickverbot.at> wrote:
 On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:
 How far did you get using Fibers on Windows in the end?
 I'm using GDC for x64 Windows, and it crashes in call(), but before it
 enters the fibre function. I think it's just broken... :/
 Anyone else had problems?

 Fiber support should be reasonably stable on pretty much all flavors of W=




indows when using DMD (i.e. compiling for 32 bit). Never tested GDC=E2=80=A6=


 Mmm, I just ran some tests with DMD, seems to work. GDC, not so much :(


=20
 Is GDC broken for both 32 and 64 bit, or just 64 bit?
=20
 I haven't tested x32, I work with x64 exclusively.


The x64 fiber code isn't very well tested. It's possible something got misse=
d for setting up the stack properly.=20=



 May 28 2012