------- Comment #4 from yichen dot xie at gmail dot com 2006-02-24 23:06
-------
> Why not let the OS do its job? I still don't understand that idea.
It's a thread library that builds on top of pthreads, so yes, OS is doing its
job, and we're doing more on top of that. C is a natural choice for us. Does it
help if we rename "h" to "reschedule"?
__thread array[1];
for (;;) {
// do something with array
reschedule();
}
> Actually no it is not responable in general since GCC assumes the address is
> invariant which is correct except for your little weird case. What function
Well, it may be a bit weird for any other language, but not C (IMO). It's
definitely not weird if you compare it to the kernel, which is largely written
in C.
Thread local objects are invariant within a thread, not across threads. I think
it could be dangerous for gcc to assume that function calls preserve thread
context, esp. when the function is written in assembly. At least there should
be a way to tell the compiler not to assume that, given C is a low-level
language where everything should be possible.
> are you using to save/restore the context? There are no standard C function
Very simple assembly code that stores/restores a few registers, including %esp.
C is a low level language, and it should interoperate well not only with
standard C functions, but also with assembly or any other "weird" functions.
That's what C is good for, isn't it?
> which allows for that. Even get/setcontext are POSIX but I doubt they support
> across threads correctly anyways. I know setjmp/longjmp don't for sure.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
