tech-userlevel archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
pthread_setaffinity_np(), cpuset_t, etc.
Hi folks,
Back in February/March there was discussion about cpuset_t as used by
NetBSD and cpu_set_t as used by Linux. This was in the context of the
ACE/TAO configure script failing as it assumed pthread_setaffinity_np
and pthread_getaffinity_np uses cpu_set_t. I mentioned that I was one
of the ACE/TAO maintainers and that I'd do what's necessary to get it
to work whether NetBSD changed the name of to be more compatible or
not.
I'm still running a mix of NetBSD 3 and NetBSD 4, but I created a
-current VM to test this because there's a upcoming ACE/TAO release.
If at all possible, I'd like to do what is necessary to add -current
support.
For the time being, I've added support to typedef cpu_set_t in terms
of cpuset_t. But I wonder if this could cause problems if various
third party packages/libraries start doing the same. It seems much
better if NetBSD itself would provide this compatibility typedef,
similar to how it provides both uintXX_t and u_intXX_t, u_short and
ushort, etc. I can send a PR with a patch if this seems desirable.
The second problem I ran into was that pthread_setaffinity_np() takes
a cpuset_t* argument, where ACE's wrapper facade assumes it would be a
const cpuset_t*. Is there any reason why this is not? It appears
that kernel treats the argument as const in the underlying
__sched_setaffinity system call as if it was a const ptr. I can send
a PR with a patch if this seems desirable too.
Thanks,
--jtc
--
J.T. Conklin
Home |
Main Index |
Thread Index |
Old Index