[vlc-devel] [PATCH] file extension manager (fixed patch)

[Rémi Denis-Courmont]

Le vendredi 20 février 2009 17:22:37 ßєŋ, vous avez écrit :
> Can't size_t be more than 32bit on 32bit system on certain circumstance ?

That depends what you call a 32-bits system.

> I guess it can. Anyway C lake a specific type for index. It's really
> architecture dependant (some oldies preffer 16bit index, some only have
> unsigned indexing ...)
> What we can expect from a C compiler is that it handles properly int
> since it is the most used index type. From my point of view using size_t
> should be use when you know the loop may be quiet large but int is the best
> average choice for «well known» finite loops. Using size_t point out this
> code may loop over large buffer (eg larger than int size like a mmaped file
> or something that usually used size_t).

If you want to be pedantic...

size_t is defined as the return type of the sizeof() operator, and is hence 
the natural type for (unsigned) array item index. int is defined as at least 
16-bits. This is wrong.

> But it's your call but i'm pretty sure most loop in VLC code use int index.

Old code does, especially due to the table macros. Most newer code uses 
size_t.

> > We can have multiple instances in a single process, in the same or in
> > different thread.
>
> Multiple instances of the core ?

We can have multiple instances created from the same thread as well as 
different threads of the same process.

> I mean there is necessary a part of the code that initialise things
> before the program forks into thread or process.

Only on Windows. There we have the DLL entry point in src/misc/threads.c.

> If it is a process, I don't care. Each have to initialise its 
> extension pool by calling fileext_init() or used an already initialised one
> that became two of them after the fork.

Actually, LibVLC cannot live through fork().

> Only thread trigger race condition so I have to be sure that fileext_Init()
> is called before any thread that might call fileext public function is
> created. I thought the part of the code I have added my init call was
> matching this condition.

That place is called before the running LibVLC instance creates threads. But 
we can make no assumption about the caller of LibVLC, or other LibVLC 
instances.

> If not please tell me where I have to do put it. 

-- 
Rémi Denis-Courmont
http://git.remlab.net/cgi-bin/gitweb.cgi?p=vlc-courmisch.git;a=summary