Support Thread features.

[kekyo]

Basic features.

• [X] System.Threading.Thread
• [ ] System.Threading.ThreadPool
• [X] Thread local storage
• [X] Collaborate GC (Giant lock)
• [X] Collaborate GC (Concurrent)

What support platforms

• [X] Windows (Native Win32)
• [ ] Linux pthreads
• [ ] Azure Sphere pthreads
• [ ] FreeRTOS (M5Stack)
• [X] No-threading environment (UEFI)

Advanced features.

• [ ] System.Threading.Tasks.Task

• How optimize handling for Tasks.

[kekyo]

Let there be thread ;)

7140e9bca425946728d3acc62ec0fc6fbacf21d7

The thread control block now defines IL2C_THREAD_CONTROL_BLOCK. And their's inside into System.Threading.Thread. Is it coming from?

First "Main thread" come from Main entry point. Currently IL2C supposes "il2c_initialize()" and "il2c_shutdown()" calling by same thread context. So, once example is initializing first thread context into il2c_initialize().

But it isn't everything. We can invoke first entry point from another thread context.

I feel we can acquire it inside into "il2c_link_execution_frame()". Because the anonymous native thread context will invoke IL2C's method, we have to initialize IL2C's thread context if anonymous threads enter the IL2C's world.

[kekyo]

First threading bones implemented. 🍰

It contains supporting for applying the arbitrary thread context. It begins on the native thread stacks, they'll enter the IL2C world by the method calling. (Exactly it means the Main method.)

The arbitrary thread is applied implicitly managed thread context (will allocates System.Threading.Thread into the heap memory.) Because IL2C runtime has to construct execution frame each threads. Current implementation is the Thread class contains both execution frames and exception frames. I feel it behavior isn't good manner.

[kekyo]

I made concurrent GC implementation 🎉 It still has mutex locks at the execution link/unlink, but it's locking at each threads.