David Brownell writes: > 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.
OK. I think that ought to be possible in POSIX threads. > 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. I don't understand what you can do about this. Some signals are delivered asynchronously, and some are not. > 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. This doesn't seem to make any sense at all. I thought the idea was to make a portable API for signals, but we seem severely to have drifted. Andrew. _______________________________________________ Classpathx-discuss mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpathx-discuss
