Michael, On Wed, Apr 1, 2009 at 6:46 AM, Michael Kerrisk <[email protected] > wrote:
> On Wed, Apr 1, 2009 at 4:26 AM, Oleg Nesterov <[email protected]> wrote: > > On 03/24, Thomas Gleixner wrote: > >> > >> sys_kill has a counterpart sys_tgkill which allows to send signals to > >> a particular thread. sys_rt_sigqueueinfo is lacking such a counterpart. > >> > >> Aside of the asymetry it is a show stopper for migrating applications > >> from other unix-alike RTOSes. > >> > >> The following patch series implements rt_tgsigqueueinfo and hooks it > >> up for x86. > >> > >> Changes since V1: > >> - match rt_siqqueueinfo and rt_tgsigqueueinfo handling of > >> info.si_pid/si_uid > > > > I think this all is correct. And I think "Changes since V1" are good, > > rt_tgsigqueueinfo() should not play with si_pid/si_uid. > > > > Reviewed-by: Oleg Nesterov <[email protected]> > > I had two concerns with earlier iteraions of this patch ( > http://thread.gmane.org/gmane.linux.kernel/799866/focus=667 ): > > [[ > 1) With rt_siqueueinfo(), we can get the PID (TGID) of the sender, > which enables the receiver of the signal to know who the sender was, > and perhaps use that information to (for example) send a signal in the > other direction. > > With rt_tgsigqueueinfo(), we don't quite have that ability: all that > the receiver gets is the TGID of the sender, not the TID. This means > that we can't (for example) send a signal back to the precise thread > that signaled us. I'm not sure if this matters or not (but perhaps it > might when sender and receiver are in the same process?). I'm also > not sure whether we want to do anything about this (i.e., extending > siginfo_t to include a si_tid field), but I wanted to point out this > assymetry w.r.t. to rt_sigqueueinfo(), in case you had not considered > it. > > 2) With rt_sigqueueinfo(), we can specify the si_pid and and si_uid > fields that should be sent to the receiver. This is not possible with > rt_tgsigqueueinfo(), which always supplied the caller';s PID and UID > in the si_pid and si_uid fields sent to the receiver. See the > following, created using my test programs below (the 111 & 222 > arguments to t_*sigqueueinfo set the si_pid and si_uid fields in the > siginfo_t given to the *sigqueueinfo() syscall): > ]] > > Roland pointed out that the first problem could be dealt with via the > sigval associated with the signal. > > The second problem is addressed by this change: > > >> Changes since V1: > >> - match rt_siqqueueinfo and rt_tgsigqueueinfo handling of > >> info.si_pid/si_uid > > I've tested this version of the interface (using the programs shown in > the mail thread referred to above), and it works as I expect, and I Can you please pass on these test program(s) to LTP. Regards-- Subrata > > find the design otherwise sane, so: > > Acked-by: Michael Kerrisk <[email protected]> > Tested-by: Michael Kerrisk <[email protected]> > > Cheers, > > Michael >
------------------------------------------------------------------------------
_______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
