493116 - Rewrite: Upgrade content/ to new synchronization API

Status: RESOLVED DUPLICATE of bug 645263

(Core :: DOM: Core & HTML, defect)

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

I'm going to punt on upgrading nsOggDecoder at roc's request.  It's slightly non-trivial.

Comment 2

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Same for nsWaveDecoder, which uses the same type of pattern.

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Partial patch, sans aforementioned decoders

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: v2

Rotted already.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: v3

Builds on my GNU/linux and Mac targets.

Comment 6

[Arpad Borsos [:Swatinem]]

From a quick look over the patch:
I believe the Mutexes should be direct members instead of pointers, thats also what the XPCOM Thread Sync guide does.

Comment 7

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #6)
> From a quick look over the patch:
> I believe the Mutexes should be direct members instead of pointers, thats also
> what the XPCOM Thread Sync guide does.

I wholly agree, but determining when this is safe to do is very non-trivial.  I would rather leave this up to people who know the code (I don't).

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Can we use member typedefs to avoid writing mozilla:: in classes?

Everywhere we initialize a monitor or lock in the constructor to "new ...", we should turn into a direct member instead of using a pointer. It should be easy to verify that those pointers are never reassigned, so this is safe.

Comment 9

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Addressed roc's comments

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 377705 [details] [diff] [review]
Addressed roc's comments

thanks!