12915 - Need xpidl coclass attribute to specify component's thread safety

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Doug Turner (:dougt)]

Need a new attribute in IDL to specify a component thread safety.
see: http://bugzilla.mozilla.org/show_bug.cgi?id=12755

This attribute should mean that anyone implementing this interface must provide
there own thread safety.

Comment 1

[John Bandhauer]

I have this in my tree - along with other stuff.

Comment 2

[John Bandhauer]

So, we decided that this should be an attribute of the *component* declaration
(aka coclass) rather than of the interface declaration. i.e. this is a statement
about a particular implemetation class not about all implementations of the
interface.

We'll remember to add this when we add the component declaration system.

Comment 3

[John Bandhauer]

I'm not sure if this should be a marker on the whole component, or if we should
do finer granularity and allow marking particular interfaces on the component as
threadsafe.

Comment 4

[John Bandhauer]

reassigning to brendan because he owns component declarations in idl problem.

Comment 5

[Brendan Eich [:brendan]]

Mike's doing xpcdl, so this one's his.  Thread in m.xpcom is quite active still,
with fur scoring points in favor of a typelib-like solution for CDL generated
form (IMHO).

/be

Comment 6

[Mike McCabe]

Marking as assigned.  We're cookin' up a plan.

Comment 7

[Mike McCabe]

Marking as dependent on 13424, 'xpidl could use component declarations in idl'.

Pushing to m16.

Comment 8

[Mike]

M16 has been out for a while now, these bugs target milestones need to be 
updated.

Comment 9

[Mike McCabe]

[SPAM] Marking milestone 'future' as part of nsbeta3 triage.

Comment 10

[Warren Harris]

This bug is invalid. Thread-safety has nothing to do with interfaces.

Comment 11

[Mike McCabe]

The bug is valid - it doesn't refer to interfaces, but is part of a suite of
feature requests for a language for describing components.

Comment 12

[Warren Harris]

That would be cdl, not xpidl then.

Comment 13

[John Bandhauer]

...name overloading...

Last I heard the likely implementation strategy would be to have the same 
'xpidl' executable process both .idl and .cdl files. It may not work out that 
way in the end, but this assumption has caused us to use the term 'xpidl' 
loosely when talking about idl and cdl.

Comment 14

[Dawn Endico]

dp is no longer @netscape.com. changing qa contact to default for this product

Comment 15

[Phil Schwartau]

Mass-reassigning mccabe's non-JS, non-Rhino bugs to jband (34 total). 

Would like to cc mccabe; but the mass-reassign page does not allow this. 
I'll leave it up to mccabe to decide if he wants to be cc'ed on these - 

Comment 16

[John Bandhauer]

nsIClassInfo can specify this.