[FFmpeg-devel] [Jack-Devel] [PATCH] libavdevice: JACK demuxer

[Michael Niedermayer]

On Sun, Mar 15, 2009 at 03:15:18PM -0400, Paul Davis wrote:
> On Sun, Mar 15, 2009 at 6:49 AM, M?ns Rullg?rd <mans at mansr.com> wrote:
> 
> >
> > I'm guessing it works because you use only x86 and because you got
> > lucky.  Many other architectures have much more relaxed memory models,
> > particularly with regards to ordering and SMP visibility.
> >
> > Your attitude reminds me of an insulted religious fanatic, desperately
> > searching for arguments in favour his belief of choice, without
> > finding any.
> >
> > If you want to discuss technical matters, please use technical
> > arguments.  If you have none, please go away.
> 
> 
> When faced with arguments like "maybe we should uint8_t because its more
> likely to be atomic" and have that considered as a "technical argument" and

I suggested uint8_t primarely because a unsigned type was needed and uint8_t
was large enough. I belive i did not use the word atomic* or suggested that as
reason somehow ...

Also ISO C makes no gurantee about the atomicity of writes.
And in actual practice for example uint64_t will not be handled atomically
on (most) 32bit archs.
The assumtation that aligned 32bit writes are atomic may hold on all
current architectures which ffmpeg, jack and linux support. Still using
uint8_t if it is sufficicent may in theory improve compatibility with future
obscure archs.
That is my oppinion, i did not do a survey of archs ...

[...]

-- 
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/20090315/e2631e9b/attachment.pgp>