El Viernes, 18 de Febrero de 2005 15:26, Gangadhar NPK escribi�: (Sorry by answer so late)
> By CORBAesque, I meant - CORBA style oneway functions wherein the client > would fire and forget a function. This might not be a good idea in your > case as the Erlang-end of the XPCOM object might require a notification > from the 'other' (standard XPCOM / pyXPCOM) object. Yes. That's why I should use a EventQueue to send events to the thread that created an object, blocking the actual thread to get a response. I'm studing now the nsISupports Proxies, I think that the behaivour is the same: It sends an Event using an EventQueue (the eventqueue usually belongs to the thread that created the object). > Before I can think of anything, did you check up how blackconnect / > pyXPCOM do this ? Because, since you are trying to write a binding, > these two places might help you. I've read/I'm reading the blackconnect code. Is a hard lecture, It has no comments :-/, and actually I have no Idea which thread uses for object creation O:) Blackconnect have an extra comunication layer, called *Connect. The binding XPCOM-*Connect has a Proxy and a Stub classes that use events to execute the calls in thread that owns the object. plXPCOM does not have this problem: The perl interpreter runs inprocess, is executed diretly in the caller thread. I'm going to study pyXPCOM. -- Greets Keymon _______________________________________________ Mozilla-xpcom mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-xpcom
