On Thu, Oct 09, 2008 at 11:36:59PM -0700, Ryan wrote: > Hi Adam, > > It was already submitted as an RFE and got accepted yesterday as CR 6757869. > The search form on the main page can't find it though; do change requests > live somewhere else? Below is an excerpt from the confirmation email. Feel > free to bump it up from its current "P5-very low" priority if you can find it > ;) > > Note that if raise() really is supposed to be directed at all times, there's > a *very* easy fix in issig_forreal(), as nico pointed out: > > 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). > > BTW, is there any way to make the above change on my Solaris 10 system > (T5220)? Or would I need to move to SolarisExpress and recompile the kernel?
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 > [EMAIL PROTECTED] said: > > *Synopsis*: No equivalent to lwp_kill() in dtrace > > > > *Change Request ID*: 6757869 > > > > *Synopsis*: No equivalent to lwp_kill() in dtrace > > > > Product: solaris > > Category: opensolaris > > Subcategory: triage-queue > > Type: RFE > > Subtype: Status: 1-Dispatched > > Substatus: Priority: 5-Very Low > > Introduced In Release: Introduced In Build: Responsible Engineer: > > Keywords: opensolaris > > > > === *Description* > > ============================================================ > > Category > > kernel > > Sub-Category > > dtrace > > Description > > The dtrace documentation claims that "the raise action can be used to > > send a signal at a precise point in a process's execution." This is only > > really true for a single-threaded process and/or a single-processor > > machine. The raise() action *usually* delivers the resulting signal to the > > lwp the probe fired on, but there is no guarantee, especially if several > > probes raise the same signal on multiple lwps simultaneously. Though this > > behavior is consistent with the semantics of kill(), an equivalent to > > lwp_kill() would be extremely useful for truly precise delivery of signals > > in multi-threaded processes. > > Frequency > > Occasionally > > Regression > > No > > Steps to Reproduce > > Trace a multithreaded process and call raise() from several lwps at the > > same time > > Expected Result > > The signal is delivered to each lwp > > Actual Result > > Targeted lwps do not always receive the signal and non-targeted lwps may > > receive one instead > > > -- > This message posted from opensolaris.org > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org