Messages in this thread | | | Date | Fri, 20 Sep 2002 20:38:20 -0700 (PDT) | From | dean gaudet <> | Subject | Re: [ANNOUNCE] Native POSIX Thread Library 0.1 |
| |
On Fri, 20 Sep 2002, Bill Huey wrote:
> On Fri, Sep 20, 2002 at 03:30:19PM -0700, dean gaudet wrote: > > > It's better to have an explict pthread_suspend_[thread,all]() function > > > > could this be implemented by having a gc thread in a unique process group > > and then suspending the jvm process group? > > Suspending how ? via signal ?
yeah SIGSTOP to the jvm process group.
> Possibly, but having an explicit syscall() call is important since interrupts > are also suspended under that condition, pthread_cond_timedwait(), etc... > It really needs to be suspended in a way that's different than the SIGSOMETHING > mechanism. I was fixing bugs in libc_r, so I know the issues to a certain degree > and bad logic those particular corner cases was screwing me up.
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 :).
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
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.
or am i missing something?
-dean
- 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/
| |