Implementing XPCOM objects in Erlang. (Modificado por Héctor Rivas Gándara)

[Héctor Rivas Gándara]

El 31/05/2005, a las 14:50, Ulf Wiger (AL/EAB) escribió:

> Why do you want to make the gen_server reentrant
> in the first place?

I'm developing the Erlang XPCOM binding. XPCOM is component tecnology 
similar to COM used in Mozilla internals. A lot of interfaces of 
mozilla receives an object as parameter and execute callbacks on it.

My first option was implement the component instances as processes.

> Another way to implement objects is to provide a module
> with a set of APIs that operate on an abstract data type.

That's the other option.

If the object is readonly or it will be accesed only by the C++ side 
(the C++ will never do concurrent calls), there is no problem, but 
there are some otherwise:

  - The object will occasionally be passed to the XPCOM side (in C++).
  - so a reference to it must be created and the object will be stored 
in an ORB to allow the  C++ side reference it.
  - I can't known when the C++ side (or even a local process) will call 
the object and change the object state.

I mean, I can't control the object access to follow the  single 
assignment rules.

One solution can be create an "object dictionary" with entries like 
ObjectReference-ObjectState.

But this have more problems:
  - the object support concurrent access (from C++, from Erlang 
processes) and
  - must allow reentrant calls.

To solve the first I could add some logic to the Object Dictionary to 
allow lock the object state until a running method does not returns 
(simulate synchronized methods).
But then it is not reentrant, so I should use a monitored lock (the 
actual process can do reentrant calls).
But now I have other problem: If I use a monitored lock the 
XPCOM-Erlang binding must offer thread consistency (there is a call 
from Erlang to C++ and back to erlang again, the process must be the 
same)

...
Too complex all. :-/

Anyway, I probably would allow the two options by setting an option in 
the object creation function. The programmer can choose:
- use process objects if the object is not readonly and will be accesed 
by C++ and Erlang
- use record objects if the object is readonly or only accesed by the 
C++ side.

I've implemented my behaviour with callbacks like:

method(MethodName, InParams, From, State) -> {Reply, NewState}
	Reply = {ok, OutParams} | noreply | {error, Reason}.

The objects implemented with this callbacks could be easily run with 
records by simply change the behaviour code: I only need a dictionary 
that could translate ObjectRefence -> {data, ObjectData} | {process, 
ObjectPid}.


Please, comments / suggestions?

--
Greets