> "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 process, it is a thread ID
> identifying a specific thread within a process. Consequently, it may be
> necessary to pass F_SETOWN the result of gettid() instead of getpid() to
> get sensible results when F_SETSIG is used. (In current Linux threading
> implementations, a main thread�s thread ID is the same as its
> process ID. This means that a single-threaded program can equally use
> gettid() or getpid() in this scenario.)"
Interesting -- thanks very much, Vivek. Clearly my fcntl manpage is out
of date. However, it turns out that my code is already doing exactly
this:
if ( fcntl( fd, F_SETFL, fcntl( fd, F_GETFL, 0 ) | O_ASYNC | O_NONBLOCK
) == -1 ) {
uAbort( "HWCounters::uStartCounters(): Unable to setup asynchronous
notification of virtual processor's file descriptor." );
} // if
if ( fcntl( fd, F_SETSIG, SIGIO ) == -1 ) {
uAbort( "HWCounters::uStartCounters(): Unable to setup additional
information for asynchronous notification." );
} // if
if ( fcntl( fd, F_SETOWN, pid ) == -1 ) {
uAbort( "HWCounters::uStartCounters(): Unable to set ownership of
virtual processor's file descriptor." );
} // if
(Where "pid" is actually the result of a gettid call.)
> Infact, I was also facing the same issues and I have implemented the above
> methods. I have yet to analyse my results closely but my initial
> impressions are that I see some loss of samples and the signals going to
> the unintended threads. If anyone of you gets any insight on this, kindly
> let me know.
One experiment that I did was to create an extra kernel thread and
leave it parked in sigsuspend. I would expect that if the signals were
being delivered according to purely POSIX semantics, most of them would
wind up with the extra thread (since I believe POSIX prefers waking up
a thread to interrupting an active one). However, that's not actually
the behavior I see -- there are many fewer "wrong thread" signals than
I would expect. So I don't seem to be seeing either the pure-POSIX
result or this special glibc F_SETOWN behavior.
(I'll just say, for those of you keeping score at home, that this is on
a Core Duo running 2.6.20 + perfmon 070209/Ubuntu 6.10/glibc 2.4.)
- Richard
_______________________________________________
perfmon mailing list
[email protected]
http://www.hpl.hp.com/hosted/linux/mail-archives/perfmon/
