Re: pthread_setname_np API is bad

[Christos Zoulas <christos%zoulas.com@localhost>]

I think we should do something right now (even for NetBSD-9) to avoid causing pain upstream.
Even the variadic change is an improvement. I was just arguing that if we were going to
make the change, let's go all the way and fix it properly, but if people feel that there is a
chance for upstream to adopt the printflike setname_np() (I don't), let's go for it.

christos

> On Aug 9, 2019, at 7:11 PM, Kamil Rytarowski <n54%gmx.com@localhost> wrote:
> 
> On 09.08.2019 17:47, Christos Zoulas wrote:
>> I understand that I am using contrived examples. I am just pointing out that we don't
>> usually implement APIs that work 99.9999% of the time when we can implement ones
>> that work 100% of the time. It is not worth risking problems. You can always provide and
>> use enhanced ones, but that causes non-portable software. Code that uses 
>> pthread_setname_np(t, "thread%d", 1) will work on NetBSD and not compile on Linux
>> the same way code that uses pthread_fmtname_np(t, "thread%d", 1) will... Except that it
>> will be obvious that pthread_fmtname_np() is a function that NetBSD has and Linux does
>> not as opposed to an incompatibility in the implementation of pthread_setname_np(), which
>> will cause the user of the function to try to figure out who's right and how to fix it.
>> It was a mistake to provide an incompatible pthread_setname_np() in the first place, let's fix
>> it properly instead of adding a most excellent band-aid.
>> 
>> 
> 
> My only reason for my proposal was to keep API compat with the current
> users, however we can switch to the Linux API. I still think that these
> 0.00001% of cases where it would be broken are in theory, not in
> practice.. but we can go for it.
> 
> I will insist on an intermediate step here before any code changes in
> libpthread(3).
> 
> I propose to try to push the Linux version to POSIX and in case of
> seeing it rejected, adapt the Linux version as is. All currently
> relevent POSIX-like OSs already support one or the other _np() variation.
> 
> There is no pressure for a change to do it now, soon or for NetBSD 9.0
> and waiting some weeks/months is fine. If it will land NetBSD 10.0,
> there will be no harm.
> 
> <sanitizer.log>