OSDev.org

I am thinking about second wersion of my kernel in which I will implement threads. So I have some questions about their management.

I assume that every kernel have some maximum possible in the moment number of TAsks (e.g 256) and THreads (eg. 8192). And now I have dilemate ;/. Should my OS support fixed MAX number of THreads per TAsk (in this example 8192/256 = max 32). Or should it support only one THread per TAsk that will be guaranteed (256 THreads guaraneed) and the rest possible THreads could be dynamically created and destroyed by TAsks on their needs (e.g. TAsk1 has 60 threads and TAsk2 has 5)? In second option TAsks that have more needs of THreads can be supported by the cost of less THreads required TAsks that have them only one or few for e.g.

What do you think about that ?

I think there shouldnt be a limit on threads per task - webservers like apache fork threads for each incoming connection, so under heavy load there can be quite a few threads at once.

by task are you meaning process?

@Combuster: So you think I should choose first architecture. I also was thinking about it in case of safe and easy way .

@hckr83: Yes, by TAsk I mean Process. I do so because everybody know meaning "multitasking" . And what way would you choose ?

I was thinking about that and foud best way. Every process will have possibility to create some MAX number of KLT Threads that is fixed like in my first idea, but process will also have possibility to create more threads than MAX, that will be ULT supported by library, then he can also choose a way of sheduling them. I think it will be perfect but I will need to work a little bit on stack's protections management for that ULT's by library .