Mail Archives: cygwin/2008/09/02/19:01:13
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. ?
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.
> What "generated code"? You mean have gcc do this? Feel free to submit
> a patch to gcc to make this happen.
I might.
> The tls implementation is not the reason why there is no native 64 bit
I understand that gcc doesn't yet target IA64 or AMD64 Windows and
that is a /large/ blocking factor.
There are patches out there for AMD64, but it isn't clear
they are of release quality (last I checked), and they aren't upstream I think.
> 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.
> 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.
> 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.
> 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.
- Jay
--
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/
- Raw text -