On Fri, Sep 20, 2002 at 08:38:20PM -0700, dean gaudet wrote:
> SIGSTOP is different from other signals because it will stop the whole
> process group from continuing. i am completely aware of how much of a
> pain it is to actually trap signals and do something (for apache 2.0's
> design i outlawed the use of signals because of the pains of getting
> things working in 1.3.x :).
There's definitely a need for a pthread_suspend_something() call...
> doesn't the hotspot GC work something like this:
>
> - stop all threads
> - go read each thread's $pc, and find its nearest "safety point"
> - go overwrite that safety point (YUCK SELF MODIFYING CODE!! :) with
> something which will stop the thread
> - start the threads and wait for them all to get to their safety points
> - perform gc
> - undo the above mess
+ read the entire ucontext for EAX, etc... so that it can be used for GC
roots. It could be allocating something in an executing method block
that hasn't hit stack or any kind of variable storage known to the GC.
> the only part of that which looks challenging with kernel threads is the
> $pc reading part... ptrace will certainly get it for you, but that's a
> lot of syscall overhead.
And the entire ucontext.
> or am i missing something?
The ucontext. ;)
bill
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:32 EST