Lazy binding is not really a feature of TLS variables. Lazy binding is used for function calls, not variable references. TLS variables do support lazy allocation, which is not quite the same thing. It’s true that if an executable refers to a TLS variable, then that variable can not be allocated lazily. But that doesn’t really matter, as the allocation of a TLS variable referenced by an executable is essentially free. It simply becomes part of the executable’s TLS segment.

After went through a couple of TLS related documents, I still have questions. It seems to me that, by default, an executable will use IE model to access external TLS variable. With IE model, an executable can access all TLS variables in shared libraries explicitly linked with that executable. So, I think these shared objects can’t support lazy binding for this executable any more. In order to support lazy binding, either GD model or dlsym() has to be used. Am I right?

Thanks!

Eric

I have occasionally seen code that assumed that signed ints roll over nicely to a negative value when they overflow, e.g. “if (i + 100 < i) ….". A good optimizing compiler will omit the comparison because signed overflow is undefined behavior. A better compiler will emit a warning about omitting the comparison. When last I checked gcc didn't.

Off topic, I saw code recently like 'if (foo() == "bar")' which passed tests because most compilers merge (some) manifest string constants. I would expect a good compiler to warn about this, and treat the expression as always false.

We’ve not enabled -Wsign-compare in coreutils at the moment, due to some ugliness that’s introduced in the code to work around the false positives. But it is a very useful warning to enable as I for one easily miss these. For a concrete example of a portability fix see:
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commit;h=e2dbcee4

Administrators of hospitals not using strict checklist procedures should be considered criminally negligent. That members of the medical profession are not spontaneously adopting these changes wholesale speaks volumes.

Maybe a collection of hypertrophied, er, “lights”, could be kept operational (not to say “healthy”) as muscle is grown and harvested and grown again. You would need clean-room conditions, as in chip fabs. I suppose the feedstock would be hydroponic algae, solar-pumped. Whatever mix of elements are taken away with the meat would need to be fed back to the algae. It is hard to imagine such an operation running as cheaply than what is done now.

Probably more effective (somebody wake up Freeman Dyson) would be to get trees to grow meat fruits. Maybe start with a jackfruit tree…

jyasskin: Channels are neither better nor worse than the threadpool I wrote. The difference is simply that since channels are built into the language, any concurrency issues only have to be fixed in one place. Gold had to be highly portable, and there is no standard concurrency library for C++. Even the libraries planned for C++0x are too low-level to really help people avoid concurrency problems; they just standardize and clarify the operations which programmers already use. (Of course portability also precludes writing gold in Go, at least at present; I was really just thinking of the advantage of including solid concurrency support in the language.)

kcc: I didn’t mean to impugn the tool, which you’ve done a great job on. By false positives I meant cases where different threads can initialize a variable simultaneously, but they always initialize the variable to the same value. This is (as far as I know) safe on popular hosts, though it is technically a race and can fail on some unusual processors.