Re: Fixing -pthreads (Re: ports and -current)

From: David Xu <davidxu_at_viatech.com.cn>
Date: Fri, 26 Sep 2003 11:25:00 +0800
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_at_freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
>  
>
Received on Thu Sep 25 2003 - 18:20:36 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:23 UTC