Project

General

Profile

Feature #6501

Implement pthread_attr_get_np() interface

Added by Alexander Pyhalov almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Normal
Category:
lib - userland libraries
Start date:
2015-12-08
Due date:
% Done:

100%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

Glibc provides pthread_getattr_np(pthread_t thread, pthread_attr_t *attr) extension to pthreads, which allows to get actual thread attribute values describing the running thread. It would be nice to have it in illumos as a lot of software uses it.

#1

Updated by Robert Mustacchi over 4 years ago

  • Subject changed from Implement pthread_getattr_np() interface to Implement pthread_attr_get_np() interface
#2

Updated by Robert Mustacchi over 4 years ago

The following notes come from the mailing list discussion as to why we don't implement pthread_getattr_np().

The semantics that Linux has for pthread_getattr_np is that it should
actually allocate the object. Now, for illumos, FreeBSD, and NetBSD,
the pthread_attr structure is actually opaque. On Linux; however, it is
not and pthread_attr_init() doesn't allocate any memory.

NetBSD actually implements both interfaces. When that happens, NetBSD
ends up actually going ahead and allocating the attr inherently in the
interface for the users. So, that gives us two options.

1) We could just only implement pthread_attr_get_np(), for which all
consumers always know you have to allocate an object.

2) We can do that and hope that folks generally don't also call
pthread_attr_init() for that. I'll document it in the manual page.

Option one has a bit of appeal for me. It means that our interface will
be slightly tighter and we don't have to understand the assumptions that
folks are making on whether or not to call pthread_attr_init() before
calling pthread_getattr_np(). Though it does have the downside that it
reduces the compat surface slightly, that we'd get from having both.

--

Thanks to Richard Palo and Jonathan Perkin for getting me a bunch of
software using this functionality. Unfortunately I've confirmed my
fears. software like Firefox and Webkit will always initialize the
pthrad_attr_T before calling either function where as other software
like QT does not. This leaves me pretty much feeling that there's no
great way to handle this today, given that the structure of the
pthread_attr_t, while opaque, is defined to be singularly opaque.

So I'm going to have to transform this into only implementing
pthread_attr_get_np(). As otherwise we'll basically be inviting a memory
leak into every program that does this. This means that having the
symbol and leaking memory is worse than not having the symbol at all.

We'll still be able to have the BSD version, which will work fine and we
shouldn't have the same concerns.

#3

Updated by Robert Mustacchi over 4 years ago

  • Category set to lib - userland libraries
  • % Done changed from 0 to 100
  • Tags deleted (needs-triage)
#4

Updated by Electric Monk over 4 years ago

  • Status changed from New to Closed

git commit e56998eefc33ead0f12b364be915dd6bfc12a3f5

commit  e56998eefc33ead0f12b364be915dd6bfc12a3f5
Author: Robert Mustacchi <rm@joyent.com>
Date:   2016-05-19T14:45:52.000Z

    6501 Implement pthread_attr_get_np() interface
    Reviewed by: Jerry Jelinek <jerry.jelinek@joyent.com>
    Reviewed by: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
    Approved by: Garrett D'Amore <garrett@damore.org>

Also available in: Atom PDF