Date: Fri, 26 Sep 2003 11:25:00 +0800 From: David Xu <davidxu@viatech.com.cn> To: David Schwartz <davids@webmaster.com> Cc: current@FreeBSD.org Subject: Re: Fixing -pthreads (Re: ports and -current) Message-ID: <3F73B18C.9060003@viatech.com.cn> In-Reply-To: <MDEHLPKNGKAHNMBLJOLKOEMMGOAA.davids@webmaster.com> References: <MDEHLPKNGKAHNMBLJOLKOEMMGOAA.davids@webmaster.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schwartz wrote: >David Xu wrote: > > > >>I definitly agree with Dan, -pthread is too ugly, it really really is >>nothing to do with compiler and should be removed. >> >> > > Really? What if invoking the threading library required the compiler to >compile code differently? Surely it might require that on some platforms, >say certain optimizations weren't thread safe. You're looking at this from >the FreeBSD perspective rather than the GCC perspective. > > If you worry about that GCC should generate thread safe code, then they should have another switch not -pthread, think about we want GCC to generate thread safe code for our kernel, then what switch is needed ? if you think -pthread forces GCC to generate thread safe code, then for our kernel, we need -freebsd-kernel switch ? > > >>If someone >>thinks -pthread >>should be kept, then think about Microsoft, you are doing >>Microsoft way and >>cause lots of trouble when I am programmming on Windows, >>Microsoft has two >>version of c library, threaded library and non-threaded library, >>it need a >>compiler flag -MT to link a thread library, then lots of library conflict >>with this flag at linking time because some were compiled with >>-MT some were >>not, this is rather annoying. This is a bit OT, but I hope we can >>avoid such decision bug. >> >> > > You can't avoid this. Suppose that some optimizations have to be disabled >to make code thread safe and say these optimizations are significant. Then >what would you do? Compile all code with the optimizations disabled and lose >performance for all the apps that aren't threaded? You can't change the fact >that threaded code and non-threaded code are incompatible on some platforms. > > > >>Many software use autoconf, autconf prefers -lpthread than >>-pthread, it even prefers -lc_r then -pthread (if I remembered it right ). >> >> > > And then autconf breaks when what you need to do to make pthreads works >changes. What happens if the next threading library requires compiler flags? >Or generates incompatible object code? > Break what ? I don't think we are forcing GCC to add another switch for our special threading library. All we want to do is resolving conflict between several thread libraries. We now have libc_r, libkse 1:1, libkse M:N, libthr, what library should be default for -pthread switch ? > > >>if system has a libpthread there, it will generate Makefile to >>use -lpthread >>not -pthread, obviously -pthread is not suggested to use. >> >> > > Not suggested by whom? The whole point of '-pthread' was to have a way to >say, "I want to use this standard". If '-pthread' is wrong, so is '-ansi'. >So is '-std=<whatever>'. > > pthread is not a language, -ansi is a language switch. > > >>One word, just let -pthread die. >> >> > > Only if you thing standards are a bad thing. > > I'm sorry, I told myself I'd stay out of this now. I really appreciate the >concern being shown and the direction that things are going. However, I >think '-pthread' is a good thing. It's nice to have a portable way to say >that I want to compile POSIX code. What good is a standard if there's no >standard way to get to it? > > If you are really programming according POSIX standard, then you should use _POSIX_SOURCE_XXX etc macros in your source code, not a magic compiler switch, it is not portable. Regards, David Xu > DS > > >_______________________________________________ >freebsd-current@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-current >To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F73B18C.9060003>