pthread_attr_[g|s]etaffinity_np

pthread_attr_[g|s]etaffinity_np

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

Hello, again,
when trying to link against OpenMP (gomp to be more precise) I ran
into undefined-symbol errors for these functions. For the moment I am
avoiding this problem by adding some weak aliases that do nothing and
return ENOSYS.

I have not yet looked into the details, but I can't imagine that it
would be too difficult to implement them in musl. What would be the
general feeling about including such NP function in one form or
another in musl?

Thanks
Jens


-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: pthread_attr_[g|s]etaffinity_np

[Szabolcs Nagy]

* Jens Gustedt <jens.gustedt@inria.fr> [2018-01-03 16:08:22 +0100]:
> when trying to link against OpenMP (gomp to be more precise) I ran
> into undefined-symbol errors for these functions. For the moment I am
> avoiding this problem by adding some weak aliases that do nothing and
> return ENOSYS.

i think libgomp detects support at configure time
so if you build gcc against musl you should get a
dummy implementation of the affinity stuff but at
least it links. (and then all libgomp tests pass
with gcc-6 and gcc-7)

Re: pthread_attr_[g|s]etaffinity_np

[Jens Gustedt]

[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]

Hello Szabolcs,

On Wed, 3 Jan 2018 18:41:18 +0100 Szabolcs Nagy <nsz@port70.net> wrote:

> * Jens Gustedt <jens.gustedt@inria.fr> [2018-01-03 16:08:22 +0100]:
> > when trying to link against OpenMP (gomp to be more precise) I ran
> > into undefined-symbol errors for these functions. For the moment I
> > am avoiding this problem by adding some weak aliases that do
> > nothing and return ENOSYS.  
> 
> i think libgomp detects support at configure time
> so if you build gcc against musl you should get a
> dummy implementation of the affinity stuff but at
> least it links. (and then all libgomp tests pass
> with gcc-6 and gcc-7)

Ok, that explains why it hasn't yet hurt people. I am testing on a
mixed environment, debian with musl in /usr/local. For all other
things static linking gcc stuff (libatomic e.g) works fine, I just ran
into that one.

The downside of these interfaces is that the state for these calls is
kept in the cpu_set_t argument. This would have to be copied /
allocated to the pthread_attr_t. That in turn would drag in malloc
etc. and thereby complicate things for the type (need for a pointer
"field") and pthread_attr_destroy (avoid memory leak).

So probably I'll keep the trivial wrappers with weak symbols inside my
own interface to OpenMP.

Thanks
Jens

-- 
:: INRIA Nancy Grand Est ::: Camus ::::::: ICube/ICPS :::
:: ::::::::::::::: office Strasbourg : +33 368854536   ::
:: :::::::::::::::::::::: gsm France : +33 651400183   ::
:: ::::::::::::::: gsm international : +49 15737185122 ::
:: http://icube-icps.unistra.fr/index.php/Jens_Gustedt ::

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: pthread_attr_[g|s]etaffinity_np

[Rich Felker]

On Wed, Jan 03, 2018 at 04:08:22PM +0100, Jens Gustedt wrote:
> Hello, again,
> when trying to link against OpenMP (gomp to be more precise) I ran
> into undefined-symbol errors for these functions. For the moment I am
> avoiding this problem by adding some weak aliases that do nothing and
> return ENOSYS.
> 
> I have not yet looked into the details, but I can't imagine that it
> would be too difficult to implement them in musl. What would be the
> general feeling about including such NP function in one form or
> another in musl?

It's intentional that the attr versions of these functions were
omitted because they require unbounded storage (and thus allocation)
in attr objects and the same result can be achieved just as well if
not better by pthread_setaffinity_np directly on the thread.

Rich