[Ffmpeg-devel] [PATCH] Staticising mpeg12data header
Thu Sep 21 16:54:43 CEST 2006
On Thu, Sep 21, 2006 at 12:04:45PM +0200, Michel Bardiaux wrote:
> >>It's a common enough syndrome. When there was no direct TLS support in
> >>Linux pthreads, writing about it only got you 'That would be very bad
> >>for performance, because of TLB flushing!' (or the ozone layer, or
> >>whatever). Now 2.6 and NPTL *have* direct TLS support with assist from
> >>gcc, and wow, now TLS is cool!
> >I hate TLS too.
> I dont want to be misunderstood. I agree with your criticism of the
> inconsistent attitudes. But IMHO TLS is very important; on visibility I
> dont have strong opinions, I take things as they are because I dont have
> much choice.
TLS important? Wow how did I never notice?!?! How have I been
programming for ~18 years and never missed it before?!? </sarcasm>
Seriously, TLS has NO LEGITIMATE USE whatsoever. It's the same thing
as global variables, but making them thread-local, and global
variables in themselves have no legitimate use. If you need context
info for the thread, pass a (pointer to a) context structure around on
the stack! Don't invent a new inherently nonportable mechanism to
allow yourself to be sloppy. It will just come back to bite you, just
like global variables do, when you want to reuse the code with
multiple instances in a situation where one thread per instance is not
> >Yet another GCC extension designed to lock people into
> >GCC. GNU software is no different than MS in this regard. They keep
> >adding more and more extensions that no one ever really needed in the
> >first place, but then because people get used to them and poorly
> >written software depends on them, everyone feels like they "need" GNU
> >extensions just like they "need" the latest MS Word.
> >It's all about inventing complexity for the sake of monopoly, and a
> >monopoly ruled by a piece of free software is only marginally better
> >than one ruled by proprietary software. Real software freedom comes
> >only through plurality -- respect for _simple_ standards and
> >interoperability. Overly complex standards (which all standards have
> >the thread of becoming) only serve to reinforce monopolies by making
> >the standard so difficult to implement that no one but the historical
> >implementations has a chance to finish it before the standard enters
> >its next phase of exponential growth.
> Very pertinent. Echoes Raymond's book "Cathedral and bazaar" where he
> stated quite candidly that open software development is mostly driven by
I don't really see the connection, but OK....
More information about the ffmpeg-devel