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
> except saying "don't use that, it's not portable, don't even ask,
> 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
> 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
> not at all"? I'd really rather not lie like this.
> hwloc-devel mailing list