This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why the strange stack stuf in cygwin?


On Tue, Sep 02, 2008 at 11:00:22PM +0000, Jay wrote:
>
>Is it the source code making the function calls that bothers you,
>or the code size/perf bloat?
>
> If it is the source, just hide it with macros, like:
>
> #define foo /* existing thread local stuff */ 
> #define bar /* existing thread local stuff */ 
>
>  typedef struct cygwin_threadlocals_t {  
>    int foo;  
>    int bar;  
>  } cygwin_threadlocals_t;  
>
>  /* Returns NULL under rare circumstances:  
>     threads created before cygwin1.dll loaded ("3pp") plus low memory, combined;
>     neither scenario alone returns NULL. The data will be allocated in 
>     cygwin1!DllMain(thread attach), which isn't called for threads created before
>    cygwin1.dll loads, returning FALSE under low memory. If not then, then on demand,
>    which can fail due to low memory.
>  */
>  cygwin_threadlocals_t* _cygwin_get_thread_locals(void);  
>
>   #define foo (_cygwin_get_thread_locals()->foo)  
>   #define bar (_cygwin_get_thread_locals()->bar)  
>
>I can go through and make/build/test a complete patch if the approach
>is ok.  This is how msvcrt.dll uses thread locals.  But again surely
>you considered that.  ?

Another aspect of the current implementation that I neglected to mention
is the ability for one thread to access another thread's local storage.
That is needed for the signal handler and it was a motivation for
implementing things the current way.

>  If it is the resulting object code, well, yeah, I can see that.  
>  It's what I asked -- to be faster than TlsGetValue.  
>
>> Changing a keyword from __thread to __declspec(thread) doesn't really
>> solve any problem.
>
>  I understand merely changing __thread to __declspec(thread)  
>  accomplishes nothing useful, just another compilation error.  
>
>  I meant implementing __thread in gcc. 
>  (actually briefly I was confused) 
>  Which would generate code. Which would have to do something.. 
>  The Visual C++ implementation is in between TlsGetValue and the existing
>   cygwin implementation in size/perf. Around three instructions per
>   reference, no function call. 

If I'm reading this right, I told you that __thread wasn't implemented
and your solution was that it should be implemented.  Not a real productive
exchange there.

>>What "generated code"?  You mean have gcc do this?  Feel free to submit
>>a patch to gcc to make this happen.
>
>I might.



>> FUD to assume that the mechanism used for the 
>> 32-bit stack manipulation could not be adopted for 64-bit. 
>
>   True that the top of the stack should work on other architectures. 
>   But it still seems somehow yucky to me. 

Subjective statements like "yucky" are not a great way to convince people
that you have a strong objective case.

>>rather than making silly pedantic and empty arguments I'd rather that
>>you contributed to making things better.  That is if you were truely up
>>to it capable.
>
>I am capable of contributing changes.  Agreement on what they should be
>is the hard part.

I'll make it easy for you: I'm not going to accept a patch which changes
every thread-local reference to a macro.  An implementation of __thread
for gcc (assuming it isn't already available) for windows would be
considered given the constraint that I mention above.

>>D:\src\cygwin-snapshot-20080822-1\winsup\cygwin\init.cc(140):        respawn_wow64_process ();
>>This has nothing to do with the "strange stack stuff" that you are
>>objecting to.
>
>I don't yet know what it's there for, but it is vaguly also "strange
>stack stuff" since it seems to not want the stack in a particular
>range.

The comment talks about what it is there for.  Using TlsGetValue would
not eliminate the need for it.

>>If it makes you nervous don't use it.  Delete it from your system.
>>This
>
>It seems the best way by far to use gcc on Windows.  Including active
>maintenance.

Most of the gcc work being done for Windows is actually being done by people
who use MinGW.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]