> > usr/src/uts/common/os/sig.c > > 530c530 > > < sigaddq(p, NULL, &info, KM_NOSLEEP); > > --- > > > sigaddq(p, t, &info, KM_NOSLEEP); > > > > However, I can imagine situations where an > undirected signal would be useful (like if the > current thread might mask the signal you care about). > > I believe there is an issue here: signals from outside a process are always > undirected. The only way to send a directed signal > is to attach to the process using /proc. > > Directed signals can mess up the state of a multi-threaded process. > Also, they can have non-intuitive effects (what if you want to SIGABORT > a process to generate a core file, but the thread you > raise() it on has all signals masked?) > > That said, I don't think there's a problem with letting undirected signals > (there are plenty of other destructive ways to change > state); I just don't think it should be the default. > > Cheers, > - jonathan
So we agree that it's good to keep undirected signals available, then. Adding the optional 'directed' flag to raise() would do the job nicely, I think. However, if raise() really is supposed to be directed, note that the suggested change in sig.c above *only* affects signals generated by dtrace and, further, would cause the traced thread to signal itself (ie nothing comes from "outside"). It would not be possible to target other threads even within the same process, let alone other processes. -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
