On 09.08.2019 18:45, Christos Zoulas wrote: > 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. > The pain with this distinct API is in reality small, almost negligible. We can resist it. Most people just copy-paste existing ifdefs from one singe source such as LLVM or stackoverlow. I track these changes in the wild and this is how it works. There is a taste issue of the unusual (void *) cast. Without this odd cast there would be no thread on this mailing list (I asked the MESA person to move this comment here to this mailing list). Delayed adoption of a standardized version of pthread_setname() pthread_getname() will result in no API & ABI breakage with any existing code as we will keep our own _np() invention, at least until we will bump major number for libpthread. and drop redundant _np() variation New all users will switch to POSIX variation. The migration will be smooth and we will avoid quick ifdefing of 150 users and pain with 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> >
Attachment:
signature.asc
Description: OpenPGP digital signature