Hello Jonathan,

06.10.98 09:14, Jonathan de Boyne Pollard wrote a message to Denis Tonn:

(sorry to fill in but i think i've got a point to make)

...
 DT>>  It doesn't operate with a kernel stack during the callback. It
 DT>> operates with the Ring 3 stack. If the process/thread stack 
 DT>> overflows, normal exception processing applies. 

 JdBP> You haven't thought about the kernel stack.  When the first
 JdBP> call to DosLoadModule or DosFreeModule calls the InitTerm
 JdBP> function in ring 3, it is several stack frames deep on the
 JdBP> kernel stack.  Even though the stack switches to the user stack
 JdBP> for the ring 3 callback, these stack frames on the kernel stack
 JdBP> *do not go away*.  They are there for the kernel to continue. 
 JdBP> When a nested DosLoadModule or DosFreeModule happens in the
 JdBP> InitTerm function, *further* stack frames are pushed onto the
 JdBP> kernel stack.  It is obvious that eventually the kernel stack
 JdBP> is going to overflow if this is nested enough times.  

Doing the second switch from ring 3 to ring 0 isn't a recursion as this has
to be done via a task state segment and a TSS holds the start values for
SS:ESP (ring 2,1,0).

 JdBP> So to add the emphasis to the question I asked above:  How does
 JdBP> the kernel deal with the *kernel stack* overflow issue that
 JdBP> results ?
...

There may be other problems because of the TSS design but IMHO not because
there are stack overflows as you described them.

C-x C-s
    Vitus

Team OS/2 Germany #835, Fidonet, OS2Net, FAX/BBS: +49-05136-893003, ...
--- Sqed/rexx 482: