[Ffmpeg-devel] [PATCH] rtp.h warning

Måns Rullgård mans
Fri Mar 23 00:10:31 CET 2007


Rich Felker <dalias at aerifal.cx> writes:

> On Thu, Mar 22, 2007 at 05:37:51PM -0400, Glenn Maynard wrote:
>> On Thu, Mar 22, 2007 at 09:13:46PM +0000, M?ns Rullg?rd wrote:
>> > > What I meant was "a good C library should have interface headers that
>> > > compile in C++ code", which ffmpeg does.
>> > 
>> > A good C library need not give a damn more about C++ than it does
>> > about Fortran, Ada, or Common Lisp.
>> 
>> They need not give a damn about threadsafety or portability, either, but
>> failure to do so will affect the opinion of the many people who need them.
>> In my opinion, a good C library requires all of threadsafety, portability
>> and a clean C++ export.  Opinions differ, obviously.
>
> Threadsafety is a direct result of not using global variables, which

There are two aspects to thread safety.  Concurrent calls operating on
different data are safe absent global writable data.  Concurrent calls
operating on same data are not necessarily safe.  In many cases, e.g.
lavc, the safety of the latter can't possibly ensured within the
library with any amount of locking.  Other times, such as in a
database, concurrent access makes perfect sense, and there a library
might want to perform the required locking.  Doing synchronization
within the library can be more efficient if this enables a more finer
grained locking than external synchronization would.  An example of
this might be a database with per-table or per-row locking that would
be impossible externally.

> are already inappropriate for a library to use.

On rare occasions, something is truly global, and then a global
variable might be appropriate.  I can't think of anything offhand,
though.

-- 
M?ns Rullg?rd
mans at mansr.com




More information about the ffmpeg-devel mailing list