Implement safe fiber recycling, fixes #753

[etcimon]

I couldn't find a zerofill algorithm in D so I had to improvise one. This is rarely even important to do b/c D automatically initializes variables as zero-filled, though TaskLocal variables are already initialized when the fiber comes around again.

[s-ludwig]

Hm.. the m_flsInit array is specifically meant to avoid this kind of cost for every new task. Since the access is always guarded by a check, there shouldn't a safety issue. What's still missing though is to destroy all variables after each task has ended. This is also very important when reference counting or similar things are going on.

[etcimon]

What's still missing though is to destroy all variables after each task has ended.

Sounds fair, I thought maybe a delegate in the core fiber would do to catch the proper type info there and destroy correctly?

[etcimon]

I remember reading that the delegate would make a GC allocation, so I replaced it by a function reference and a void*. Looks lightweight enough to me and certainly more stable than recycling the data on new connections .. which on my application meant inheriting someone else's account if you didn't have a session id.. xD

[s-ludwig]

Looks about right, only

• Instead of TaskDestructor, it should instead be a struct FLSInfo, containing the destructor function pointer, as well as the offset of the FLS variable instead of the pointer, so that it stays the same for all tasks
• TaskDestructor[] m_destructors; should be static FLSInfo[] ms_flsInfo; - no need to create one array per task anymore when the offset is stored
• Only fields with m_flsInit[id] == true should be destroyed
• Only fields with std.traits.hasElaborateDestructor!T should be destroyed for efficiency (don't set the destructor function pointer for other types) - maybe types with hasAliasing!Tcould instead be zeroed out to avoid false GC pointers

[etcimon]

Alright, all good and tested on a web app. Not sure on the long run how it's going to fare though but it looks alright

[s-ludwig]

I think this is usually going to crash. A TaskLocal will only be destroyed when the thread has ended. However, in that case the event loop has already been quit and CoreTask.getThis() returns null. So I'd just remove this.

[s-ludwig]

Apart from the destructor, looks good to merge.

[etcimon]

Done

[s-ludwig]

Okay, thanks! Merging in.