On 27 Oct 2010, at 13:56, David Xu wrote: >> Yay, it's fd_set all over again :-). >> >> It sounds like we might just need to add a sysctl and a few wrapper >> functions in userspace along the lines of (hand-wave): >> >> cpuset_t *cpuset_alloc(); >> void cpuset_free(); >> >> And perhaps some sort of API that abstracts manipulation of the set (or >> doesn't but allows the user to easily query its bounds).
> Problem is who will use the non-standard interface ? The > pthread_attr_getaffinity_np pthread_attr_setaffinity_np > and others are from glibc, which let you specify arbitrary > cpuset size but kernel only accept one size. :-) > > Though it is not POSIX, but some software start to use it, AFAIK, > Erlang language's VM start to use it for binding its scheduler > thread to cpu, we have to live with it. We still lack of some functions > to let it compile without modification, one is it wants to know > cpu topology, and other crappy functions it wants to use is: > sched_getaffinity, sched_setaffinity, which one guy thought each > thread is just a process which has a PID. :-) > I don't know how it uses Solaris processor binding interface. I see two separate problems here: (1) Providing potentially non-portable APIs that do the right thing, and do it well. (2) Providing definitely portable APIs whose implementation is as robust as possible given their flawed semantics. I.e., don't crash on common use. The latter should be implemented in terms of the former. Robert_______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
