After a few hours of reverse-engineering x86 SEH, I finally got exceptions in fibers working on my Windows Server 2008 R2 box ? sorry, Sean, that I reported them working after your previous changes, I was only testing on my XP VM. Please see: https://github.com/D-Programming-Language/druntime/pull/150 (not super-urgent, but fixes the Thrift async client code)

Anyway, while working on the code, I noticed that we are currently not saving/restoring the x87 and SSE control words. Now, I'd certainly love to keep the context switching overhead as low as possible, but should we add a pair of stmxcsr/ldmxcsr reps. fnstcw/fldcw for the sake of correctness?

If necessary, I can prepare a patch.

David

I say +1 for correctness. Much more important than the negligible speed loss.

Regards,
Alex

On Mon, Feb 13, 2012 at 7:51 PM, David Nadlinger <code at klickverbot.at> wrote:
> After a few hours of reverse-engineering x86 SEH, I finally got exceptions in fibers working on my Windows Server 2008 R2 box ? sorry, Sean, that I reported them working after your previous changes, I was only testing on my XP VM. Please see: https://github.com/D-Programming-Language/druntime/pull/150 (not super-urgent, but fixes the Thrift async client code)
>
> Anyway, while working on the code, I noticed that we are currently not saving/restoring the x87 and SSE control words. Now, I'd certainly love to keep the context switching overhead as low as possible, but should we add a pair of stmxcsr/ldmxcsr reps. fnstcw/fldcw for the sake of correctness?
>
> If necessary, I can prepare a patch.
>
> David
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

On Feb 13, 2012, at 10:51 AM, David Nadlinger wrote:

> After a few hours of reverse-engineering x86 SEH, I finally got exceptions in fibers working on my Windows Server 2008 R2 box ? sorry, Sean, that I reported them working after your previous changes, I was only testing on my XP VM. Please see: https://github.com/D-Programming-Language/druntime/pull/150 (not super-urgent, but fixes the Thrift async client code)
> 
> Anyway, while working on the code, I noticed that we are currently not saving/restoring the x87 and SSE control words. Now, I'd certainly love to keep the context switching overhead as low as possible, but should we add a pair of stmxcsr/ldmxcsr reps. fnstcw/fldcw for the sake of correctness?

Oops!  I really should have thought of that.  Yes, please prepare a patch.

On Mon, 13 Feb 2012 19:51:08 +0100, David Nadlinger <code at klickverbot.at> wrote:

> After a few hours of reverse-engineering x86 SEH, I finally got exceptions in fibers working on my Windows Server 2008 R2 box ? sorry, Sean, that I reported them working after your previous changes, I was only testing on my XP VM. Please see: https://github.com/D-Programming-Language/druntime/pull/150 (not super-urgent, but fixes the Thrift async client code)
>
> Anyway, while working on the code, I noticed that we are currently not saving/restoring the x87 and SSE control words. Now, I'd certainly love to keep the context switching overhead as low as possible, but should we add a pair of stmxcsr/ldmxcsr reps. fnstcw/fldcw for the sake of correctness?
>
> If necessary, I can prepare a patch.
>
> David
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime

NO!

http://d-programming-language.org/float.html - Rounding Control

Calling Fiber.yield is just returning in an unusual manner. As Fibers are not preemptive we shouldn't do that.

Besides:
Do you have any success with the Windows+Fiber+GC bug
http://d.puremagic.com/issues/show_bug.cgi?id=7229.

On Feb 13, 2012, at 12:26 PM, Martin Nowak wrote:
> 
> Calling Fiber.yield is just returning in an unusual manner. As Fibers are not preemptive we shouldn't do that.

I think Fibers can be used in two different ways.  The first is for iteration and such, where the synchronous nature is intended.  The second is within thread pools and such, where the fiber really is a logical thread.  Any ideas for how to resolve the two?

On Mon, 13 Feb 2012 21:52:13 +0100, Sean Kelly <sean at invisibleduck.org> wrote:

> On Feb 13, 2012, at 12:26 PM, Martin Nowak wrote:
>>
>> Calling Fiber.yield is just returning in an unusual manner. As Fibers are not preemptive we shouldn't do that.
>
> I think Fibers can be used in two different ways.  The first is for iteration and such, where the synchronous nature is intended.  The second is within thread pools and such, where the fiber really is a logical thread.  Any ideas for how to resolve the two?

That doesn't really change the matter. When a function returns it should
reset
it's FPU control word if it was changed. Whether or not it's executed in a
thread pool
makes no difference. Now if somebody calls Fiber.yield he has to restore
all callee
cleanup state because he is literally returning to the outer context.