🚀 go-pugleaf

In article <1989Oct19.143604.21001@rpi.edu> ander@pawl.rpi.edu (Michael R. Primm) writes:
>
>Threads are easy to use and much more useful than fork()ing around :-).  
>
I am having problem dynamically creating and killing threads.  Suppose I am a 
function that gets called everytime a thread is to be spawned.  If I allocate
a stack for the thread in my own stack, then that stack is going to get
de-allocated everytime I exit.  If I using the heap space for the thread
stack, who will be freeing it?  Definitely not the thread itself?
Am I suppose to manage all those stacks also?  Such is not the case in Mach,
I think.

Another question relating to threads, do you know how to tell if you have 
any thread running?  Some API calls that serve an anologous purpose to
DosCWait(), but for threads will be nice.

According to all I have read on OS/2 semaphores, it seems like not only don't
they support counting semaphores, they don't even eliminate the problem of
race condition because any thread could be scheduled next.  OS/2 has three
different kinds of semaphores with ten(?) semaphore functions, yet none of
them are as powerful as the one defined by Dijkstra?  What I want is a counting
semaphores with a FIFO queue. Sometime ago somebody wrote an article in the
Microsoft Systems Journal showing how one could "easily" implement a counting
semaphore using the available APIs.  But the counting semaphore he showed
did not have a FIFO queue associated with it, so one still has the race
condition.  Please correct me if I am wrong.  


sugih