[FIXED] Seeking debug tips for Kaffe on NSPR

Godmar Back gback at marker.cs.utah.edu
Tue May 26 15:38:13 PDT 1998


> 
> Also, fstat is probably not the only thing missing from the syscall
> interface; process spawning needs attention (right now, I don't even
> try to support it).  The problem is fork() --- NSPR doesn't export any
> such functionality for the excellent reason that it's very difficult
> to support well on Windows; instead, they have a one-step process
> spawning function.  I *believe* that handling process creation
> properly through the syscall interface would also allow fixfd to be
> eliminated, which is all to the good; fixfd violates abstraction by
> design.
> 

 Agreed, but I won't have the time to tackle the process issue
anytime soon.  Tim had already removed fixfd, I had to put it back
in for the pipes surrounding the fork() call when I added the async IO
for jthreads, just as you surmised. 

> 
> The thread interface structure already has a GcWalkThreads entry which
> is supposed to walk the stacks (and registers) of the running threads;
> that's the code I have which calls walkConservative.  The question
> is how it finds walkConservative to call it.  Right now, the name is
> just wired in, which can't be good; it would be better to either have
> it in the GC dispatch table, or to pass a function pointer in as an
> argument to GcWalkThreads (as in the NSPR GC hooks).

I understand what you're saying.

Imagine Kaffe would not use a conservative gc, but a precise gc instead.


More information about the kaffe mailing list