Re: pthread_setaffinity_np(), cpuset_t, etc.

[christos%astron.com@localhost (Christos Zoulas)]

In article <87od8yziuh.fsf%orac.acorntoolworks.com@localhost>,
J.T. Conklin <jtc%acorntoolworks.com@localhost> wrote:
>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.

Send-pr please

christos