Date: Tue, 23 Sep 2003 19:35:29 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: Marcin Dalecki <mdcki@gmx.net> Cc: Freebsd Current <current@freebsd.org> Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <Pine.GSO.4.10.10309231920460.24353-100000@pcnet5.pcnet.com> In-Reply-To: <3F70D4EB.1080604@gmx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 24 Sep 2003, Marcin Dalecki wrote: > Daniel Eischen wrote: > > On Tue, 23 Sep 2003, Marcin Dalecki wrote: > > > > > >>Scott Long wrote: > >> > >> > >>>I'm perfectly happy to support the libkse->libpthread switch, and I'm > >>>perfectly happy to support making libpthread be the default threading > >>>library. But, I strongly believe that we need to also treat -pthread > >>>sanely. > >> > >>You have to decide what the therading lib should be indeed. > >>However recent expirence shows that a 1:n model seems to be the > >>one the world over you is gearing around: Linux never did anything else. > >>Windows anyway. Solaris switched from n:m to 1:n on the step between > >>version 8 and 9.... Having two of them isn't the solution for me as a developer > >>since I'm simply not interresed in debugging both cases. > > > > > > This is a reason why -pthread shouldn't imply linking > > to any one library. If you only want to deal with > > libthr or libthread (KSE in 1:1 mode), then you are > > free to choose them and only them. > > Last time I heard that "this is a link time option". So you are supposed > to change the lib under the hood of the applications controll. The applications is free to link to whatever it wants; we're not changing that. If it wants to link to 1:1 libthr or whatever, then it had better be sure to use -lthr because -pthread won't do it regardless of whether it is a NOOP or not. > Making -ptherad empty is silly. If you are going to disable this > perfectly sensible compiler switch then BY EVERY MEANS better make it BREAK > CYRING ABOUT THIS FACT. But don't just silent it.... Making -pthread a NOOP _would_ (*) break the application in the link stage; it would be obvious when the application failed to link with lots of unresolved pthread symbols. (*) Unless we want to support LD_PRELOAD being able to change the threads library. -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10309231920460.24353-100000>