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 =

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

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
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
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
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 "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
prev sibling next sibling parent 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 =


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

section of the forum or is there a formal tracker? http://d.puremagic.com/issues/=
Apr 18 2012
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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 =

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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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=


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


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=

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=

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=

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 next sibling parent 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.

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. =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.

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

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
prev sibling next sibling parent "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 point: Unity3D. The entire engine is built around C#'s 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). This capability makes C# very compelling for game development, 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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 
 in point: Unity3D. The entire engine is built around C#'s 
 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).

"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
prev sibling next sibling parent 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" =


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 =

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
prev sibling next sibling parent "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.

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
prev sibling next sibling parent 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, =


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


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. =


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

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
prev sibling next sibling parent 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 =


this work on platforms with built-in TLS could be quite tricky.
 Note that this would somewhat sabotage their usefulness as coroutines, =

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
prev sibling 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.

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 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.

happens :)
Apr 20 2012
prev sibling next sibling parent "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.

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
prev sibling next sibling 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 =




this work on platforms with built-in TLS could be quite tricky.
 Note that this would somewhat sabotage their usefulness as =



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 =


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

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 =

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 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 next sibling parent Manu <turkeyman gmail.com> writes:
--0023543a2b3ac02f7404c08d3841
Content-Type: text/plain; charset=UTF-8

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? --0023543a2b3ac02f7404c08d3841 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 18 April 2012 21:48, Andrew Lauritzen <span d= ir=3D"ltr">&lt;<a href=3D"mailto:andrew.lauritzen gmail.com" target=3D"_bla= nk">andrew.lauritzen gmail.com</a>&gt;</span> wrote:<br><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex"> I sent this to the mailing list but as it appears to be awaiting moderation= , here might be a more appropriate place for discussion.<br> <br> Throwing exceptions from fibers seems buggy on Windows in the latest D2 run= time. Even a small modification to the example given in the unit test (addi= ng unrelated exception handling to the same scope) fails with a &quot;Stack= Overflow&quot; exception then tons of access violations:<br> <br> =C2=A0 enum MSG =3D &quot;Test message.&quot;;<br> =C2=A0 string caughtMsg;<br> =C2=A0 (new Fiber({<br> =C2=A0 =C2=A0 =C2=A0 try<br> =C2=A0 =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 throw new Exception(MSG);<br> =C2=A0 =C2=A0 =C2=A0 }<br> =C2=A0 =C2=A0 =C2=A0 catch (Exception e)<br> =C2=A0 =C2=A0 =C2=A0 {<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 caughtMsg =3D e.msg;<br> =C2=A0 =C2=A0 =C2=A0 }<br> =C2=A0 })).call();<br> =C2=A0 assert(caughtMsg =3D=3D MSG);<br> =C2=A0 // Add these two lines<br> =C2=A0 try { caughtMsg =3D &quot;Hello&quot;; }<br> =C2=A0 catch (Exception e) { caughtMsg =3D &quot;World&quot;; }<br> <br> It seems brittle as well. Adding a &quot;assert(caughtMsg =3D=3D &quot;Hell= o&quot;);&quot; to the end of the above program for instance avoids the acc= ess violations (but still shows the stack overflow in the debugger). Simila= rly playing with the caughtMsg assignments (omitting one) or adding another= assert at the end of the program will sometimes cause the program to run w= ithout error. This is in debug mode with optimizations off to theoretically= avoid dead code elimination, but clearly something is easily thrown off.<b= r> <br> I take it that not too many people are using Fibers on windows, but I reall= y need them for a project that I&#39;m working on. Alternatively I&#39;ve c= onsidered trying to wrap native Win32 API Fibers to accomplish something si= milar, but I&#39;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&#39;m trying to do in a clean a= nd efficient manner. I&#39;ve considered switching to Go, but I&#39;ve got = some really handy mixins in D that would become copy-pasted stuff in Go pre= sumably.<br> <br> I&#39;m running a 32-bit D application on Windows 7 x64. I&#39;ve tried on = several machines with the same results, and the same issue was present in 2= .058 as well.<br> <br> Any ideas?<br> </blockquote></div><br><div>How far did you get using Fibers on Windows in = the end?</div><div>I&#39;m using GDC for x64 Windows, and it crashes in cal= l(), but before it enters the fibre function.=C2=A0I think it&#39;s just br= oken... :/</div> <div>Anyone else had problems?</div> --0023543a2b3ac02f7404c08d3841--
May 21 2012
prev sibling next sibling parent "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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf300facc92c577a04c08e8e53
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=

Hmm, well I am limited to x64, and therefore GDC... :/ --20cf300facc92c577a04c08e8e53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 21 May 2012 19:16, David Nadlinger <span dir= =3D"ltr">&lt;<a href=3D"mailto:see klickverbot.at" target=3D"_blank">see kl= ickverbot.at</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> How far did you get using Fibers on Windows in the end?<br> I&#39;m using GDC for x64 Windows, and it crashes in call(), but before it<= br> enters the fibre function. I think it&#39;s just broken... :/<br> Anyone else had problems?<br> </blockquote> <br></div> Fiber support should be reasonably stable on pretty much all flavors of Win= dows when using DMD (i.e. compiling for 32 bit). Never tested GDC=E2=80=A6<= /blockquote><div><br></div><div>Hmm, well I am limited to x64, and therefor= e GDC... :/</div> </div> --20cf300facc92c577a04c08e8e53--
May 21 2012
prev sibling next sibling parent 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
 =


talk-video.html
=20
 I've been digging around and just found Mikola's coroutine =


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
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--bcaec5246308aaa91b04c092f6a7
Content-Type: text/plain; charset=UTF-8

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:



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


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. --bcaec5246308aaa91b04c092f6a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 21 May 2012 21:15, Sean Kelly <span dir=3D"lt= r">&lt;<a href=3D"mailto:sean invisibleduck.org" target=3D"_blank">sean inv= isibleduck.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On May 21, 2012, at 11:05 AM, Jacob= Carlborg wrote:<br> <br> &gt; On 2012-04-20 20:08, Sean Kelly wrote:<br> &gt;<br> &gt;&gt; <a href=3D"http://petermodzelewski.blogspot.com/2008/10/tango-conf= erence-2008-fibers-talk-video.html" target=3D"_blank">http://petermodzelews= ki.blogspot.com/2008/10/tango-conference-2008-fibers-talk-video.html</a><br=

&gt;&gt;<br> &gt;&gt; I&#39;ve been digging around and just found Mikola&#39;s coroutine= implementation on my hard drive. =C2=A0It would have to be updated, but I = do have the code. =C2=A0Maybe this should be added to Druntime.<br> &gt;<br> &gt; I thought that this is what&#39;s used in druntime and Tango already?<= br> <br> </div></div>Druntime Fiber is equivalent to Mikola&#39;s StackThreads, but = there&#39;s no Coroutine class in Druntime.</blockquote></div><br><div>What= &#39;s the distinction between a fiber and a coroutine? I thought they were= basically synonymous.</div> --bcaec5246308aaa91b04c092f6a7--
May 21 2012
prev sibling next 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:

 =



talk-video.html
 I've been digging around and just found Mikola's coroutine =



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 =

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

Coroutine is a tad higher-level, but they're functionally identical.
May 21 2012
prev sibling next sibling parent Manu <turkeyman gmail.com> writes:
--20cf303b40636551b904c0a25af4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=

Mmm, I just ran some tests with DMD, seems to work. GDC, not so much :( --20cf303b40636551b904c0a25af4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 21 May 2012 19:16, David Nadlinger <span dir= =3D"ltr">&lt;<a href=3D"mailto:see klickverbot.at" target=3D"_blank">see kl= ickverbot.at</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"im">On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> How far did you get using Fibers on Windows in the end?<br> I&#39;m using GDC for x64 Windows, and it crashes in call(), but before it<= br> enters the fibre function. I think it&#39;s just broken... :/<br> Anyone else had problems?<br> </blockquote> <br></div> Fiber support should be reasonably stable on pretty much all flavors of Win= dows when using DMD (i.e. compiling for 32 bit). Never tested GDC=E2=80=A6<= /blockquote><div><br></div><div>Mmm, I just ran some tests with DMD, seems = to work. GDC, not so much :(</div> </div> --20cf303b40636551b904c0a25af4--
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 =

=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:
--bcaec5246308b2d9c504c1146016
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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


 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. --bcaec5246308b2d9c504c1146016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 24 May 2012 21:08, Sean Kelly <span dir=3D"lt= r">&lt;<a href=3D"mailto:sean invisibleduck.org" target=3D"_blank">sean inv= isibleduck.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s= tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On May 22, 2012, at 9:17 AM, Manu w= rote:<br> <br> &gt; On 21 May 2012 19:16, David Nadlinger &lt;<a href=3D"mailto:see klickv= erbot.at">see klickverbot.at</a>&gt; wrote:<br> &gt; On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:<br> &gt; How far did you get using Fibers on Windows in the end?<br> &gt; I&#39;m using GDC for x64 Windows, and it crashes in call(), but befor= e it<br> &gt; enters the fibre function. I think it&#39;s just broken... :/<br> &gt; Anyone else had problems?<br> &gt;<br> &gt; Fiber support should be reasonably stable on pretty much all flavors o= f Windows when using DMD (i.e. compiling for 32 bit). Never tested GDC=E2= =80=A6<br> &gt;<br> &gt; Mmm, I just ran some tests with DMD, seems to work. GDC, not so much := (<br> <br> </div></div>Is GDC broken for both 32 and 64 bit, or just 64 bit?<br> </blockquote></div><br><div>I haven&#39;t tested x32, I work with x64 exclu= sively.</div> --bcaec5246308b2d9c504c1146016--
May 28 2012
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
--Apple-Mail-74F5DA79-2383-46F2-AB1E-CEB7D1FB1EDD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	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=


 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? =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= --Apple-Mail-74F5DA79-2383-46F2-AB1E-CEB7D1FB1EDD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head></head><body bgcolor=3D"#FFFFFF"><div>On May 28, 2012, at 1:19 A= M, Manu &lt;<a href=3D"mailto:turkeyman gmail.com">turkeyman gmail.com</a>&g= t; wrote:<br><br></div><div></div><blockquote type=3D"cite"><div><div class=3D= "gmail_quote">On 24 May 2012 21:08, Sean Kelly <span dir=3D"ltr">&lt;<a href= =3D"mailto:sean invisibleduck.org" target=3D"_blank">sean invisibleduck.org<= /a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On May 22, 2012, at 9:17 AM, Manu wr= ote:<br> <br> &gt; On 21 May 2012 19:16, David Nadlinger &lt;<a href=3D"mailto:see klickve= rbot.at">see klickverbot.at</a>&gt; wrote:<br> &gt; On Monday, 21 May 2012 at 15:04:56 UTC, Manu wrote:<br> &gt; How far did you get using Fibers on Windows in the end?<br> &gt; I'm using GDC for x64 Windows, and it crashes in call(), but before it<= br> &gt; enters the fibre function. I think it's just broken... :/<br> &gt; Anyone else had problems?<br> &gt;<br> &gt; 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= <br> &gt;<br> &gt; Mmm, I just ran some tests with DMD, seems to work. GDC, not so much :(= <br> <br> </div></div>Is GDC broken for both 32 and 64 bit, or just 64 bit?<br> </blockquote></div><br><div>I haven't tested x32, I work with x64 exclusivel= y.</div> </div></blockquote><br><div>The x64 fiber code isn't very well tested. It's p= ossible something got missed for setting up the stack properly.&nbsp;</div><= /body></html>= --Apple-Mail-74F5DA79-2383-46F2-AB1E-CEB7D1FB1EDD--
May 28 2012