One thing to not forget is that some (many?) applications don't care a
whit about portability to other OS's. You view feature X as a
portability horror; they view it as a feature.
Hence, they may actually *want* to take advantage of the ability to
pin a specific thread (that is not the current thread).
On Nov 11, 2009, at 4:03 PM, Samuel Thibault wrote:
Brice Goglin, le Thu 12 Nov 2009 00:31:48 +0100, a écrit :
> The problem is that our hwloc/Linux does not implement
> set_proc_cpubind() so far.
But it can implement one that assumes that the target process is
singlethreaded, i.e. in hwloc_set_proc_cpubind distinguish between
HWLOC_CPUBIND_PROCESS being set or not, or by just passing the policy
flag as such to OS hooks.
> * document in hwloc.h that it may bind a single thread if the
> application (wrongly) passes a tid
I'd really rather avoid even mentioning tids in the hwloc
documentation
except saying "don't use that, it's not portable, don't even ask,
you'd
be horrified".
> * document that hwloc_plpa_sched_setaffinity now works on processes
> instead of pids and that application should use thread_t and
> set_thread_cpubind for local threads
Or pass 0 to express "the current thread", which was already valid for
plpa_sched_setaffinity, and _is_ portable (and should already have
been
the only thing that truly portable applications use).
> * maybe return -ENOSYS on Linux if STRICT is given?
I guess you mean return 0 if STRICT is not given, and mean "it's not
strict because we haven't actually done it for all the threads, or
even
not at all"? I'd really rather not lie like this.
Samuel
_______________________________________________
hwloc-devel mailing list
hwloc-de...@open-mpi.org
http://www.open-mpi.org/mailman/listinfo.cgi/hwloc-devel
--
Jeff Squyres
jsquy...@cisco.com
