tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pthread_setname_np API is bad



On Tue, Aug 6, 2019 at 7:17 AM Kamil Rytarowski <n54%gmx.com@localhost> wrote:
>
> On 06.08.2019 07:19, Matt Turner wrote:
> > On Mon, Aug 5, 2019 at 10:06 PM Thor Lancelot Simon <tls%panix.com@localhost> wrote:
> >>
> >> On Fri, Aug 02, 2019 at 09:29:27PM -0700, Matt Turner wrote:
> >>>
> >>> So great, you made your API incompatible with everyone else for zero
> >>> gain. /o\
> >>
> >> And so forth.
> >>
> >> Is there some reason for the snotty attitude?  Whether you're right or
> >> wrong you're not likely to persuade anyone that way.
> >
> > Well, yes, actually. It's a waste of my time to deal with useless API
> > incompatibilities.
> >
> > Feel free to disregard my whole email based on the perceived attitude,
> > if you're unhappy with it.
> >
> > I was just trying to do the right thing, and I don't intend to expend
> > any more effort advocating for this change. It doesn't matter to me
> > whether you take the suggestion or even whether Mesa works on NetBSD,
> > but it might matter to you. So, ¯\_(ツ)_/¯
> >
>
> I propose to change the function signatures on the next ABI bump to:
>
> int pthread_setname_np(pthread_t, const char * restrict format, ...)
> __printflike(2, 3);
>
> int pthread_attr_setname_np(pthread_attr_t *, const char * restrict
> format, ...*) __printflike(2, 3);
>
> This way we will keep API compat for all the current users and keep
> compiler checks for safe usage.
>
> Personally, I find it convenient to use it like pthread_setname_np(t[i],
> "thread %d, i) and I would like to keep using it.

FWIW, I think that's a better suggestion than either of mine. I support that.


Home | Main Index | Thread Index | Old Index