(add Roland) On 07/29, Peter Zijlstra wrote: > > On Mon, 2009-07-27 at 18:51 +0200, stephane eranian wrote: > > > > POSIX does not mandate that asynchronous signals be delivered > > to the thread in which they originated. Any thread in the process > > may process the signal, assuming it does not have the signal > > blocked.
Yes. I now nothing about POSIX, but this is what Linux does at least. I don't think we can/should change this behaviour. > fcntl(2) for F_SETOWN says: > > If a non-zero value is given to F_SETSIG in a multi‐ threaded > process running with a threading library that supports thread groups > (e.g., NPTL), then a positive value given to F_SETOWN has a > different meaning: instead of being a process ID identifying a whole > pro‐ cess, it is a thread ID identifying a specific thread within a > process. Heh. Definitely this is not what Linux does ;) > Which seems to imply that when we feed fcntl(F_SETOWN) a TID instead of > a PID it should deliver SIGIO to the thread instead of the whole process > -- which, to me, seems a sane semantic. I am not sure I understand the man above... But to me it looks like we should always send a private signal when fown->signum != 0 ? The change should be simple, but as you pointed out we can break things. Oleg. ------------------------------------------------------------------------------ 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
