Date:	Mon, 3 Aug 2009 14:53:18 +0200
From:	stephane eranian <eranian@...glemail.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>, oleg@...hat.com,
	mingo@...e.hu, linux-kernel@...r.kernel.org, tglx@...utronix.de,
	robert.richter@....com, paulus@...ba.org, andi@...stfloor.org,
	mpjohn@...ibm.com, cel@...ibm.com, cjashfor@...ibm.com,
	mucci@...s.utk.edu, terpstra@...s.utk.edu,
	perfmon2-devel@...ts.sourceforge.net, mtk.manpages@...glemail.com,
	roland@...hat.com
Subject: Re: [RFC][PATCH] fcntl: F_[SG]ETOWN_TID

Andrew,

On Fri, Jul 31, 2009 at 11:11 PM, Andrew
Morton<akpm@...ux-foundation.org> wrote:
> On Fri, 31 Jul 2009 10:35:20 +0200
> Peter Zijlstra <a.p.zijlstra@...llo.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.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists