[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