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/
