Re: [patch 0/3] add rt_tgsigqueueinfo syscall [RESEND]

On 2/28/09, Roland McGrath [off-list ref] wrote:

quoted

With respect to the first point, it seems to me reasonably likely that
there would be use cases where the receiving thread wants to know the
thread ID of the sender -- especially when sender and receiver are in
the same process.

But expecting si_pid to play that role is bizarre.

Oh -- I wasn't suggeting that si_pid do that task; I was instead
wondering if we needed an additional si_threadid field (or some such).

It's never what any
POSIX-like program would do, both since POSIX says si_pid is a process ID,
and because there are no POSIX-like interfaces at all that use Linux TIDs
to refer to threads.

(Nod.)

Wanting this only seems plausible within one process.

We are in agreement.

In that case, sender
and recipient know they share memory.  The normal thing to do (and what
POSIX applications will do) is to store that info somewhere pointed to by
the sigval.

Good point.  That would be another of dealing with point I wondered
about, and probably better than my idea.

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
git://git.kernel.org/pub/scm/docs/man-pages/man-pages.git
man-pages online: http://www.kernel.org/doc/man-pages/online_pages.html
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html