Sorry for my late involvement in this issue. My intuition is, using signal for thread suspension is not absolutely necessary. Well sometimes it is an easy solution. I'd suggest us to use the current wrapper solution until we have more thorough considerations in it.
A couple of years ago, when I was working in another JVM implementation, I developed the thread suspension code with signal. It reduced the STW GC pause time obviously, but later I dropped that mechanism because of the unsafe nature. Thread suspension with signal requires the suspended thread to wait in signal handler for a semaphore posted by the suspending thread to resume. This is not always safe because, in some system semaphore implementation uses signal or is sensitive to signal. So it is not recommended to use signal for thread suspension. Actually it is recommended not to suspend thread preemptively at all. Threads should better always stop themselves. On the other hand, this is not easy to deal with in native code development if without preemptive suspension when the native code developer does not follow certain rule to facilitate thread voluntarily stop. When Linux current threading lib was implemented by Ulrich and Ingo years ago, I sent email asking them to add some thread suspension mechanism in the NPTL. Well the request was not strongly justified, and we don't have direct thread suspension support in Linux today. :( I will re-examine the preemptive thread suspension code in DRLVM. Hopefully we can drop them. Gregory and Alexei please throw in your opinions as well. Thanks, xiaofeng 2009/4/2 Alexei Fedotov <[email protected]>: > Hello, Tim, > I was able to do a partial research on unix/hysock.c > > 1. The patch [1] shows that when select() was used Artem Aliev had prepared > a proper patch with while (result == -1 && errno == EINTR). > > 2. Currently the logic of select) call in unix/hysock.c is different, with > no while loop. > > > [1] https://issues.apache.org/jira/browse/HARMONY-1904 > > > > > > 2009/4/1 Tim Ellison <[email protected]> > >> Alexei Fedotov wrote: >> > As Mark said [1], the main difference in socket handling between jvms >> > is system call interruption. DRLVM sends termination signals to system >> > calls before stop the world garbage collection, hence they should be >> > restarted (i.e. any system call should be put in a loop). >> >> Without getting into a debate about the virtues of interrupting an OS >> call for GC purposes <g>, can you point me towards any examples of >> native code that correctly handles these signals today? I'd like to >> reuse a working example rather than hack something up. >> >> Regards, >> Tim >> >> > Thanks! >> > >> > [1] http://markmail.org/thread/kbs7bfcnkcfggyc4 >> >> > > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://www.telecom-express.ru/ > http://people.apache.org/~aaf/ > -- http://people.apache.org/~xli
