[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: CVS commit: src/lib
On 2013-03-25, at 20:14, Emmanuel Dreyfus <manu%netbsd.org@localhost> wrote:
> It would fix one instance of the problem, but it will appear again
> somewhere else later. We cannot expect third party program to always do
> The Right Thing, especially when it is outside of any specification: no
> standard has a word on it, and to make things worse, Linux lets you
> dlopen a DSO with -lpthread
Having followed this debate somewhat cursory, I may way off base. I cannot help
wonder, however, if we should look at this issue from the opposite direction.
What if we turn on the "machinery" needed in order to support pthread by
default? I believe this amounted to some extra locking code. This would add
unnecessary overhead to non-threaded programs, but I'm guessing that for most
programs this overhead would not be noticeable. Then, to accommodate programs
where this overhead is unacceptable, add a "no-pthread" option that restores
the current behavior. Seems to me this kind of change is not unprecedented and
rather similar to the case, years ago, when we switched from static to dynamic
Finally, I have a question about the degree of the "regression". Typically,
NetBSD has provided a high degree of binary compatibility. In the past, when I
have upgraded the system code, most (all?) packages continue to function
without having to be recompiled. In this case, that appears not to be the case.
Do the latest changes restore binary compatibility?
Main Index |
Thread Index |