Andrew, On Fri, Jul 31, 2009 at 11:11 PM, Andrew Morton<a...@linux-foundation.org> wrote: > On Fri, 31 Jul 2009 10:35:20 +0200 > Peter Zijlstra <a.p.zijls...@chello.nl> wrote: > >> In order to direct the SIGIO signal to a particular thread of a >> multi-threaded application we cannot, like suggested by the manpage, put >> a TID into the regular fcntl(F_SETOWN) call. It will still be send to >> the whole process of which that thread is part. >> >> Since people do want to properly direct SIGIO we introduce F_SETOWN_TID, >> which functions similarly to F_SETOWN, except positive arguments are >> interpreted as TIDs and negative arguments are interpreted as PIDs. >> >> This extension is fully bug compatible with the old F_GETOWN >> implementation in that F_GETOWN_TID will be troubled by the negative >> return value for PIDs similarly to F_GETOWN's trouble with process >> groups. > > I'd be interested in seeing a bit more explanation about the "people do > want to properly direct SIGIO" thing - use cases, how the current code > causes them problems, etc. As it stands, it's a bit of a mystery-patch. > I have explained that in my initial post on LKML. Here is a link to it: http://lkml.org/lkml/2009/7/27/242
Basically, in the context of self-monitoring threads (which is very common), you want the sample notification to be asynchronous and yet delivered to a particular thread, i.e., the one in which the sample was recorded. The asynchronous notification is required because you are monitoring yourself. Asynchronous signals are normally delivered to any thread within the process. In my message, I described the algorithm currently implemented by the kernel. As Peter found out, the man page seems to indicate that if you specify a TID instead a PID with F_SETOWN, then the kernel should interpret this as meaning this particular thread, but this is not what is implemented right now. Self-monitoring has specific needs, you don't necessarily want SIGIO to always be delivered to the thread in which it originated. That is why, I have suggested a new code path. It is also important that backward compatibility be maintained. >> [ compile tested only so far ] > > I will continue to lurk :) > >> arch/parisc/include/asm/fcntl.h | 2 + >> fs/fcntl.c | 64 +++++++++++++++++++++++++++++++++----- >> include/asm-generic/fcntl.h | 4 ++ >> include/linux/fs.h | 11 +++++- >> net/socket.c | 2 +- > > OK. > > > > Alpha has private definitions of F_SETSIG and F_GETSIG which are > identical to the generic ones. That's somewhat logical, given that > alpha's F_SETOWN/F_GETOWN _differ_ from the asm-generic ones. > > Alpha appears to have made the decision to spell out _all_ the F_* > flags, given that some of them are different. That has some merit, I > guess. > > But your patch broke that. > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ perfmon2-devel mailing list perfmon2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/perfmon2-devel
