On Monday 13 June 2005 9:36 am, Andrew Haley wrote: > > Well, signals happen when they happen -- you have no control over > that. Also, there's no portable way to determine which thread in a > multi-threaded process receives a signal. If a JVM maps Java threads > to OS threads, you have no way to determine that either.
Well, I thought the general policy of how to mix signals and threads was succinctly described as blocking signals in all threads, and using sigwait() in one dedicated thread. All other strategies being error prone. How that should map to Java runtimes, I won't speculate. :) > Because of the tight restrictions on what you can do in a signal > handler, I can't immediately see anything better than creating a > thread ahead of time and triggering that thread from the signal > handler. The thread, in turn, creates handler threads as required. > That way, it doesn't matter what thread receives the signal. Nah, it's better to just prevent signals from being async in userspace in the first place. Don't use signal handlers if you're using threads. Remember, even in single-threaded code it's always been hard to make async signals work right. If you think you need async signals, be a Real Man and write hardware IRQ handlers that access chip registers. (In Java!) Let spinlocks be your friends, and don't pay attention to the realtime people behind the curtain, telling you about how IRQ handlers should run in threads too. - Dave _______________________________________________ Classpathx-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpathx-discuss
