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.
signature.asc
Description: OpenPGP digital signature
