thread limits

Hi all,

After watching the talk on threading, I have some questions related to number of possible threads. First, Ivan mentions that it may support 16 bits thread IDs. He also says that Go would work well with these threads, however, I don’t see how you could have enough threads. Some people run 100k or even 1,000,000 coroutines in Go, but 16bit would only give you 65k threads. Assuming a 65k limit, Go would need to limit thread usage and instead allocate its own stacklets which wouldn’t be in a WKR and use more PLB power. Allowing more threads is an option, but the more threads you allow, the less space is available per stacklet.

Going one step further, what would stop a user from spawning until no thread ids are left? I am guessing that in such a case there would be a trap and the OS would solve the problem? This could lead to reuse hazards so the policy model would need to take that into account somehow.

Would this also make virtualization impossible on a Mill? If I had a hypervisor (assume built just for Mill) running many copies of Linux, how would I control the use of thread IDs or even how much memory was used on a per guest basis? You could control how much of the address space you assign, but that wouldn’t include stacklets.

Speaking of virtualization, it seems like you would also have to figure out how to inform each process of the OS services location. For example, if there is an OS portal to spawn a process, how would an application know where to find that portal? This could be put in a “well known location” but that wouldn’t virtualize well when there is one virtual address space.