[FFmpeg-devel] parse_date using localtime etc.

[Michael Niedermayer]

On Fri, Feb 06, 2009 at 03:13:43PM +0100, Reimar D?ffinger wrote:
> On Fri, Feb 06, 2009 at 02:47:05PM +0100, Michael Niedermayer wrote:
> > On Fri, Feb 06, 2009 at 12:49:20PM +0100, Reimar D?ffinger wrote:
> > > That does not solve anything (actually it creates even _more_ issues)
> > > since you could pass the pointer to a different thread.
> > 
> > and why would this be a problem?
> > I definitly meant a non broken implementation of thread
> > local storage, that is each thread stores its copy at a distinct address
> > and thus a pointer to it would be valid in any thread.
> 
> The thread exits and then? Either you have a memleak or an invalid
> pointer (that is the additional issue, and it means such an "improved"
> version would not be 100% compatible).

well thats the same issue as accessing a someting after free(), you asked
for it ...
and there are 2kinds of applications, threaded and single thread

if you write a multithreaded app without considering that there are
multiple threads then really its not too unexpected that this fails.


> There is also my argument that it would not work with custom cooperative
> userspace-threading implementation, since the libc will not know of that
> threading implementation (or to put it different, thread-local storage
> means you can only use "the one approved" threading model you libc
> relies on).

alot of things wont work in that case, for example errno. So i dont see
in how far localtime() would be relevant


> Also when the same thread calls localtime it will change the contents of
> all localtime() results it passed to other threads.

yes, if you write code that uses global variables to communicat beetween
threads without any precautions but then maybe localtime() will be your
least problem


> Also, independent of threading, the localtime API is using a global variable
> (even if it is thread-local) with all the issues that has.

i agree about that being bad design ...


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

> ... defining _GNU_SOURCE...
For the love of all that is holy, and some that is not, don't do that.
-- Luca & Mans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090206/3097f8e6/attachment.pgp>