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 

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

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.



J.T. Conklin

Home | Main Index | Thread Index | Old Index